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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Sun, May 29, 2011 at 8:27 PM, Scott Dorr <j.scott.dorr@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.