Re: [Libevent-users] Unitialized Memory Read when pushing >64 events at once

[Adrian Chadd <adrian@xxxxxxxxxxxxxxx>]

On Sat, Jun 04, 2011, Nick Mathewson wrote:
> On Sat, Jun 4, 2011 at 2:14 PM, Scott Dorr <j.scott.dorr@xxxxxxxxx> wrote:
> > Sorry I didn't get a chance to fiddle with this until just now. ?The short
> > program below does generate uninitialized memory reads when executing the
> > printf(). ?If I add a memset() right after the events[200] declaration
> > (before the epoll_wait() call), the uninitialized memory issue goes away,
> > though it's clear the epoll underpinnings are actually filling in that
> > memory before we get back to our program space (gdb examination looks
> > clean).
> > Looks like a false positive to me at this point as well.
> 
> Okay.  Do you reckon it would be helpful to add a -DPURIFY build
> option to libevent 2.1 to try to suppress these false positives at the
> expense of a little needless computation?  I'm hesitant to add any
> slowdown needlessly, but compatibility with testing tools is pretty
> important to folks.

We just had an:

if (running_on_valgrind)
    memset(epollarray, 0, size);

You can then build it with -DVALGRIND and if it detects running on valgrind,
it'll add whatever hints or zero whatever RAM is needed to keep valgrind
happy.

2c,


Adrian

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.