Using Purify with db2 CLI application

[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_utlStripTra ilingBlanks(uns igned char*,unsigned char*,long*)
[libdb2.so.1]
short SQLConnect1(CLI _CONNECTINFO*,u nsigned char*,short,uns igned
char*,short,uns igned 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 getPrivateChunk sFromOs(SqloChu nk,void**) [sqlomset.C]
int SMemSet::alloca teChunkGroup(Sq loChunk,SqloChu nk,unsigned long)
[libdb2.so.1]
int SMemSet::getCon tiguousChunks(S qloChunk,unsign ed
long,SChunkGrp* *,SqloChunk*) [libdb2.so.1]
int SMemPool::getNe wChunkSubgroup( unsigned,unsign ed long)
[libdb2.so.1]
int SMemPool::alloc ateMemoryBlock( unsigned,unsign ed,unsigned
long,void**,Sql oChunkSubgroup* *) [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

[Will Honea]

On Sun, 13 Mar 2005 07:30:50 UTC "hcc" <hc****@yahoo.c om> 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_utlStripTra ilingBlanks(uns igned char*,unsigned char*,long*)
[libdb2.so.1]
short SQLConnect1(CLI _CONNECTINFO*,u nsigned char*,short,uns igned
char*,short,uns igned 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 getPrivateChunk sFromOs(SqloChu nk,void**) [sqlomset.C]
int SMemSet::alloca teChunkGroup(Sq loChunk,SqloChu nk,unsigned long)
[libdb2.so.1]
int SMemSet::getCon tiguousChunks(S qloChunk,unsign ed
long,SChunkGrp* *,SqloChunk*) [libdb2.so.1]
int SMemPool::getNe wChunkSubgroup( unsigned,unsign ed long)
[libdb2.so.1]
int SMemPool::alloc ateMemoryBlock( unsigned,unsign ed,unsigned
long,void**,Sql oChunkSubgroup* *) [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

[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

[Will Honea]

On Sun, 13 Mar 2005 20:57:13 UTC "hcc" <hc****@yahoo.c om> 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

[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