On Sat, Jun 04, 2011, Nick Mathewson wrote:
> On Sat, Jun 4, 2011 at 2:14 PM, Scott Dorr <j.scott.d...@gmail.com> 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 majord...@freehaven.net with
unsubscribe libevent-users in the body.
