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.
I also looked through event.c, and couldn't find a particular logic path
that would cause it, nor could I get valgrind to duplicate it with simple
libevent test code.
Sometimes when valgrind indicates this error, I split the logic into two
separate conditionals as it's not always apparent which particular object
is at fault. It seems pretty obvious to me it wasn't ev_flags, as that was
explicitly initialised, leaving only ev_res - but as I said I couldn't track
it down here. Is it possible you were using an event struct which hadn't
been passed to event_set() yet (just a sanity check for a simple bug)?
> However, it's useful to suppress noise in valgrind output, and there's
> no real cost to initializing ev_res at event_set time. Thus the attached
> patch.
Certainly agreed, except for the "noise" part
(http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals).
-cl
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users
