On Sun, May 29, 2011 at 8:27 PM, Scott Dorr <[email protected]> wrote:
> Purify complains about Unitialized Memory Reads when I try to push more than
> 64 events onto the queue at the same time. This is in a 64bit application
> running on RHEL linux. I'm currently using libevent-2.0.10-stable.
> epoll_dispatch triggers a set of of 4 UMRs for each event past the 64th that
> I push onto the event base. The first three are 1 byte reads on the stack
> (which it says is 20 bytes below the frame pointer in the epoll_dispatch
> function), and the fourth is a 4 byte read which is 388 bytes into a
> malloc'd block of 768 bytes. That malloc'd block was a realloc() that was
> called by epoll_dispatch->event_mm_realloc_
> I don't have libevent instrumented, otherwise I'd provide more detail. Is
> this a known issue?
Yuck. If this is still present in 2.0.11-stable (and I don't know why
it wouldn't be) we should track it down. Is there more info you can
copy and paste? Stack info would help a lot here, if you can get it.
Failing that, I don't have purify, and I don't have your test code, so
trying to reproduce this on my own could be tricky. Does this also
happen with valgrind? And do you have a small sample program you can
share? Is this with the changelist feature, or no?
Looking at the final case you mention, the only thing in
epoll_dispatch that calls mm_realloc is the code near the end of the
function that grows the events array. But so far as I can tell, we
never use any part of that array that isn't set by our call to
epoll_wait. Is it possible that purify doesn't know that when
epoll_wait returns "res", it has set the first "res" elements of its
third element?
Below is a short program I tried to use to reproduce this, but
valgrind didn't tell me about any reads of uninitialized memory. Does
purify complain about the program below?
Some possibilities include:
* It's a false positive from purify for some reason.
* It's an uninitialized-read that purify can find but valgrind can not.
* I'm using valgrind wrong.
* My test program below does not produce the bug.
* Something else that I'm not thinking of right now.
========
#include <stdio.h>
#include <event2/event.h>
void nilcb(evutil_socket_t s, short what, void *arg)
{
}
int main(int c, char **v)
{
struct event_base *base;
int fd[128];
struct event *ev[128];
int i;
base = event_base_new();
for (i=0;i<128;++i) {
fd[i] = socket(AF_INET, SOCK_DGRAM, 0);
if (fd[i]<0) {
perror("socket");
return 1;
}
ev[i] = event_new(base, fd[i], EV_WRITE, nilcb, NULL);
event_add(ev[i], NULL);
}
for (i=0;i<10;++i)
event_base_loop(base, EVLOOP_ONCE);
for (i=0;i<128;++i) {
event_free(ev[i]);
}
event_base_free(base);
return 0;
}
======
***********************************************************************
To unsubscribe, send an e-mail to [email protected] with
unsubscribe libevent-users in the body.
