|
From: Heiko G. <hg...@te...> - 2003-09-23 15:07:07
|
Hi,
I have a question concerning uninitialised memory on GNU/Linux. Valgrind
tells me a databuffer is uninitialised although the databuffer contains
the correct data. How can that be? I thought uninitialized means random
data.
This is what happens:
==================
I'm using the db2 CLI to retrieve data from a db2 database. Valgrind
(20030725) detects the following:
==2671== Conditional jump or move depends on uninitialised value(s)
==2671== at 0x40020840: strncpy (in usr/lib/valgrind/vgskin_memcheck.so)
==2671== by 0x408BA52B: stringcopy (string2.c:159)
==2671== by 0x408DF7B6: AtaqDBColumn::setUnchanged(unsigned, unsigned)
(ataqdb.cpp:2315)
This happens after a sql select when the db2 CLI copies data from database
colums to the bound buffers (which are definitly initialized!) in my c++
program. After filling these buffers by the db2 routines in the db2.so, in
one particular char column the 8th byte is uninitialized according to
valgrind (if I set this byte before the strncpy above is reached, valgrind
does not complain anymore).
Anyway the content of the data is absolute correct including the 8th byte.
What ever happens in the db2.so, if the ("uninitialized") byte contains the
right data how can it be uninitialized? Somehow the data must have been
copied there. There are no messages concerning invalid memory access or
similar.
Any hints?
Thanks
Heiko
|
|
From: Jeremy F. <je...@go...> - 2003-09-24 14:37:52
|
On Tue, 2003-09-23 at 17:02, Heiko Gerdau wrote:
> Anyway the content of the data is absolute correct including the 8th byte.
> What ever happens in the db2.so, if the ("uninitialized") byte contains the
> right data how can it be uninitialized? Somehow the data must have been
> copied there. There are no messages concerning invalid memory access or
> similar.
> Any hints?
Do you know what mechanism the client library uses to talk to the
database? If they're on the same machine, could they be using shared
memory?
J
|
|
From: Heiko G. <hg...@te...> - 2003-09-25 13:34:50
|
On Wednesday 24 September 2003 15:35, Jeremy Fitzhardinge wrote:
> On Tue, 2003-09-23 at 17:02, Heiko Gerdau wrote:
> > Anyway the content of the data is absolute correct including the 8th
> > byte. What ever happens in the db2.so, if the ("uninitialized") byte
> > contains the right data how can it be uninitialized? Somehow the data
> > must have been copied there. There are no messages concerning invalid
> > memory access or similar.
> > Any hints?
>
> Do you know what mechanism the client library uses to talk to the
> database? If they're on the same machine, could they be using shared
> memory?
No, I don't know, but the data is stored on disk and the problem arises
also in a network. Even with shared memory, how would you explain it? I
don't even can imagine a theoretical explanation for this single
uninitialized byte.
Anyway, thanks for your attention.
Heiko
|
|
From: Jeremy F. <je...@go...> - 2003-09-25 19:40:09
|
On Thu, 2003-09-25 at 15:34, Heiko Gerdau wrote: > No, I don't know, but the data is stored on disk and the problem arises > also in a network. Even with shared memory, how would you explain it? I > don't even can imagine a theoretical explanation for this single > uninitialized byte. Hard to tell. It might be an instruction sequence which generates a known value from unknown inputs, which Valgrind doesn't recognize. J |