|
From: Ashley P. <as...@pi...> - 2009-02-12 18:32:53
|
On 12 Feb 2009, at 18:21, Micah N Gorrell wrote:
> On Thu, 12 Feb 2009, Ashley Pittman wrote:
>> On 12 Feb 2009, at 16:34, Micah N Gorrell wrote:
>>> 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?
>
> 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.
Yes.
> 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.
I would strongly advise compiling OpenSSL with -DPURIFY on at least one
machine and fixing anything it throws up so that the program is
valgrind clean in at least one environment, simply setting up
suppressions and not verifying it anywhere as you can't test it
everywhere is a waste of a good opportunity IMHO.
Ashley,
|