[Libevent-users] [PATCH] initialize ev_res

[Scott Lamb]

Christopher Layne wrote:
> On Thu, Jul 19, 2007 at 01:14:58PM -0700, Scott Lamb wrote:
>> When I use "valgrind --tool=memcheck" on a libevent-based program, it
>> gives the following complaint:
>>
>> ==15442== Conditional jump or move depends on uninitialised value(s)
>> ==15442==    at 0x4C0F2D3: event_add (event.c:632)
>> ==15442==    by 0x405EE4: main_loop (net.c:356)
>> ==15442==    by 0x411853: main (tincd.c:329)
>>
>> Here's the relevant portion of event.c:
>>
>> 632                if ((ev->ev_flags & EVLIST_ACTIVE) &&
>> 633                    (ev->ev_res & EV_TIMEOUT)) {
>>
>> I've looked through the libevent code and verified that ev_res is always
>> initialized when (ev_flags & EVLIST_ACTIVE) is true, so there's no real
>> bug here.
> 
> You wouldn't happen to have a copy of the code or atleast code segment
> which was tickling this would you?
> 
> When valgrind complains about uninitialised values, it's not in the fashion
> of gcc in that "this could be uninitialised - so watch out" type of noise. It
> really is an uninitalised area being read from.

Yes, I also think it was really an uninitialized area being read from, 
but not one to worry about.

As I'm sure you know, && indicates lazy evaluation - the second half 
doesn't get evaluated if the first half is false. But this was an 
optimized build of libevent, and I believe gcc decided that there were 
no side effects from evaluating (ev->ev_res & EV_TIMEOUT) early and that 
it would be faster to do the reads simultaneously, so it did so. gcc was 
almost right about "no side effects" - I don't blame it for not knowing 
that valgrind would complain about undefined values.

valgrind is complaining about an intermediate value. Essentially, the 
code did "0 && junk". The *result* is correctly defined as 0. valgrind's 
just not quite smart enough to realize that though junk was loaded into 
a register, it didn't actually affect the result of a comparison or any 
other operation.

Scott