Re: [Libevent-users] [PATCH] initialize ev_res
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:
632if ((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
Re: [Libevent-users] evhttp_dispatch_callback fix (so '/some?this=that' does not match '/something')
Thank you. I love unit tests :-) Submitted to trunk. Niels. On 8/2/07, Elliot Foster [EMAIL PROTECTED] wrote: Here's a follow-up with a regression test (attached.) Elliot Elliot Foster wrote: Another quick fix for the dispatch callback, for when it goes through available callbacks looking for a match. The problem is that if the request URI has an argument, the comparison is done on the bytes before the url parameter separator. The result is that the lookup will result in mismatches, especially for a request URI like '/?some_arg=some_val' that will match the first callback found. Two potential fixes are attached, one that modifies the string to replace the argument separator with a null char before the strcmp, and another that checks for a null char in the potential match (at the same offset as the argument separator.) Thanks, Elliot ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] initialize ev_res
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:
632if ((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
