By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,572 Members | 946 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,572 IT Pros & Developers. It's quick & easy.

Using Purify with db2 CLI application

P: n/a
hcc
Hi,
Does anyone have experience with using Purify with db2 CLI
application? We're using Purify to diagnose some problem in our
multi-thread CLI application, and we're getting lots of the
"UMR: Uninitialized memory read" error reported by Purify. I wrote
a very short test CLI program that simply calls SQLAllocHandle,
SQLConnect, SQLDisconnect and SQLDisconnect; and Purify still
reports the same error. The following is one of them:
**** Purify instrumented hcctest (pid 4467) ****
UMR: Uninitialized memory read:
* This is occurring while in:
void CLI_scnGetChar(unsigned char*,unsigned char**,unsigned
char*,unsigned char*,unsigned char*,unsigned char*,short*)
[libdb2.so.1]
void CLI_utlStripTrailingBlanks(unsigned char*,unsigned char*,long*)
[libdb2.so.1]
short SQLConnect1(CLI_CONNECTINFO*,unsigned char*,short,unsigned
char*,short,unsigned char*,short) [libdb2.so.1]
SQLConnect [libdb2.so.1]
main [hcctest.o]
_start [crt1.o]
* Reading 1 byte from 0xee1ae in the heap.
* Address 0xee1ae is 170870 bytes into a malloc'd block at 0xc4638 of
262144 bytes.
* This block was allocated from:
malloc [rtlib.o]
int getPrivateChunksFromOs(SqloChunk,void**) [sqlomset.C]
int SMemSet::allocateChunkGroup(SqloChunk,SqloChunk,un signed long)
[libdb2.so.1]
int SMemSet::getContiguousChunks(SqloChunk,unsigned
long,SChunkGrp**,SqloChunk*) [libdb2.so.1]
int SMemPool::getNewChunkSubgroup(unsigned,unsigned long)
[libdb2.so.1]
int SMemPool::allocateMemoryBlock(unsigned,unsigned,un signed
long,void**,SqloChunkSubgroup**) [libdb2.so.1]

Does this mean there are bugs in db2 library? I use g++ and
gcc to compile/link the test program. I'd appreciate any help very
much.

--hcc

Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Sun, 13 Mar 2005 07:30:50 UTC "hcc" <hc****@yahoo.com> wrote:
Hi,
Does anyone have experience with using Purify with db2 CLI
application? We're using Purify to diagnose some problem in our
multi-thread CLI application, and we're getting lots of the
"UMR: Uninitialized memory read" error reported by Purify. I wrote
a very short test CLI program that simply calls SQLAllocHandle,
SQLConnect, SQLDisconnect and SQLDisconnect; and Purify still
reports the same error. The following is one of them:
**** Purify instrumented hcctest (pid 4467) ****
UMR: Uninitialized memory read:
* This is occurring while in:
void CLI_scnGetChar(unsigned char*,unsigned char**,unsigned
char*,unsigned char*,unsigned char*,unsigned char*,short*)
[libdb2.so.1]
void CLI_utlStripTrailingBlanks(unsigned char*,unsigned char*,long*)
[libdb2.so.1]
short SQLConnect1(CLI_CONNECTINFO*,unsigned char*,short,unsigned
char*,short,unsigned char*,short) [libdb2.so.1]
SQLConnect [libdb2.so.1]
main [hcctest.o]
_start [crt1.o]
* Reading 1 byte from 0xee1ae in the heap.
* Address 0xee1ae is 170870 bytes into a malloc'd block at 0xc4638 of
262144 bytes.
* This block was allocated from:
malloc [rtlib.o]
int getPrivateChunksFromOs(SqloChunk,void**) [sqlomset.C]
int SMemSet::allocateChunkGroup(SqloChunk,SqloChunk,un signed long)
[libdb2.so.1]
int SMemSet::getContiguousChunks(SqloChunk,unsigned
long,SChunkGrp**,SqloChunk*) [libdb2.so.1]
int SMemPool::getNewChunkSubgroup(unsigned,unsigned long)
[libdb2.so.1]
int SMemPool::allocateMemoryBlock(unsigned,unsigned,un signed
long,void**,SqloChunkSubgroup**) [libdb2.so.1]

Does this mean there are bugs in db2 library? I use g++ and
gcc to compile/link the test program. I'd appreciate any help very
much.


Not sure if it's your problem or not, but I was getting the same
warnings a few years back when the app passed a pointer to an
unititialized blob of memeory when it created a retrieve thread. The
top app then waited for a message set by the thread and launched a
second thread to process/forward the data. That gave me
serialization without any time overhead, but the second thread, the
read process, would complain that the passed data area was never
initialized since the initialization occured outside it's scope (or
existance). This was using 5.2 on OS/2 and finally cured with a
library update. Never caused a problem, obviously, but Purify
understandably thought the second thread was using uninitialized data.

--
Will Honea
Nov 12 '05 #2

P: n/a
hcc
Hi,
Thanks a lot for your reply. My small test program is actually
single thread, and all it
does is to connect to the database and then disconnect right away. We
have version 7
or 8 of db2 library, and we are using Solaris. You mention that the
warning was cured
with a library upgrade, but I think the library we are using is
up-to-date. Is it possible that
the old "bug" is introduced again in the newer version? I'd like to
find out whether now the
UMR error might have caused a problem in applications eventually.
Again I'd appreciate
any help very much.

--hcc

Nov 12 '05 #3

P: n/a
On Sun, 13 Mar 2005 20:57:13 UTC "hcc" <hc****@yahoo.com> wrote:
Hi,
Thanks a lot for your reply. My small test program is actually
single thread, and all it
does is to connect to the database and then disconnect right away. We
have version 7
or 8 of db2 library, and we are using Solaris. You mention that the
warning was cured
with a library upgrade, but I think the library we are using is
up-to-date. Is it possible that
the old "bug" is introduced again in the newer version? I'd like to
find out whether now the
UMR error might have caused a problem in applications eventually.
Again I'd appreciate
any help very much.


I'm afraid I won't be any help to you. That was, what, 6-7 years or
so back, right in the middle of the Y2K panic where we were upgrading
something about every week so I can't even say if it was the DB2
libraries, the compiler, or the in-house transport layer we were using
at the time. That whole circus is one big blur now.

Thinking about it, malloc allocates but not initialize memory so it
may well be a library bug. I'll see if I can repeat it with another
compiler version for W2K or Linux here if I can break out of the
current rat race in the next day or so. It could also be a 'so what'
warning - does the app run?

--
Will Honea
Nov 12 '05 #4

P: n/a
hcc
Hi,
My small test program does run ok; our real multi-thread db2 app.
also runs but
starts to have problem after a while. You may be right that the UMR
could just be a 'so
what' warning and might not cause any problem. I don't want to take
too much of your
time; you've already helped a lot.

--hcc

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.