|
From: Ashley P. <as...@pi...> - 2009-02-12 18:09:04
|
On 12 Feb 2009, at 16:34, Micah N Gorrell wrote:
> ==11124== Conditional jump or move depends on uninitialised value(s)
> ==11124== at 0x406508E: ReadConditionEventProcess (process.c:1272)
> ==11124== by 0x40608F9: ConnReadToCondition (connio.c:2472)
> ==11124== by 0x80524C7: HandleConnection (dmc.c:2041)
> ==11124== by 0x40C134A: start_thread (in /lib/libpthread-2.4.so)
> ==11124== by 0x471A65D: clone (in /lib/libc-2.4.so)
> ==11124== Uninitialised value was created by a heap allocation
> ==11124== at 0x4021B38: malloc (vg_replace_malloc.c:207)
> ==11124== by 0x47FA04B: (within /usr/lib/libcrypto.so.0.9.8)
>
> Below is process.c lines 1271 and 1272. Since line 1272 only has one
> variable
> I am forced o assume that valgrind thinks that it wasn't initialised.
> The call
> directly above it is setting it though. Am I missing something? How
> can that
> possibly be an uninitialised value?
>
> Before you ask this was built with no optimizations.
>
> receiveCount = SocketReceive( ce->socket, receiveStart, ioBufferSpace,
> &( ce->timeOut ), &blockedOn, &err );
> if( 0 < receiveCount ) {
> ...
Without the code or documentation for SocketReceive it's hard to say,
yes Valgrind is saying receiveCount is unitialised which in turn means
the return value from SocketRecieve was unitialised. Note that it's
possible to pass around unitialised values throughout your program,
it's only when you use them that they get reported. What is the
meaning of the err variable, does that require checking in this
context?
Another thing I notice is the use of libcrypto, this is known not to
play well with Valgrind on occasion and report false positives, this
doesn't sound like it's directly applicable in your case but it's worth
a read of the following FAQ entry to cover the background:
http://openssl.org/support/faq.html#PROG14
Ashley,
|