|
From: Micah N G. <val...@mi...> - 2009-02-12 18:21:14
|
On Thu, 12 Feb 2009, Ashley Pittman wrote:
>
> 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,
>
So, if SocketReceive returned an uninitialised value then it can cause this? So
that tells me that I should review SockReceive in more detail to try and
determine how that could happen.
I have had a lot of warnings related to OpenSSL. I've built a suppressions file
for them for now. I would prefer to rebuild OpenSSL with the -DPURIFY define
but that isn't possible on all the machines I'll be running this on, and the
suppressions file seems to do the trick. I've had to do the same thing for
another library as well (the eDirectory client libs). Those seem to really
confuse valgrind, and I'm guessing that they did that intentionally for security
reasons. I've managed to run without those libs as well using an alternate
directory so that I can make sure they aren't skewing my results too much.
So I'll review these functions more then. Thanks for the help.
Micah
|