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
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
