Niels: I will try the gdb commands you provided and will report back with the results. Also, STL maps do not invalidate iterators on erase() as far as I know (http://www.sgi.com/tech/stl/Map.html). And I'm 100% sure I never point at a deleted element.
On Wed, Mar 10, 2010 at 1:48 PM, Nick Mathewson <[email protected]> wrote: > On Wed, Mar 10, 2010 at 4:22 AM, David Titarenco > <[email protected]> wrote: > [...] > > I get my req pointer from an STL map: map<evhttp_request *,bead> that I > > iterate over. Now, I wrote a home-made timeout method that uses evtimer > for > > these long-polling connections (that I call beads). The only thing that > I'm > > worried about is that the timeout callback might be fired in the middle > of a > > (long) iteration in case of many connections (could this even happen? > -the > > It depends what you mean by an "iteration". Libevent runs callbacks > one-at-a-time. > > > which in turn also closes the connection and > > deletes map entry. > > I'm assuming that you've made sure that anything else that frees the > connection will also delete the timeout event too.? > > > But if this weird race condition DOES happen, it _should_ > > give me an STL null pointer exception, not a libevent segfault. Moreover, > is > > there any way to check and see if the req is valid or not, to at least > avoid > > a server crash? > > Your best bet here is using a tool like valgrind (which should work > with C++) or dmalloc (there is probably a C++ equivalent) to catch the > memory problem. I agree with niels that it looks like something is > getting freed too early; I'm not sure whether that's your program's > bug or Libevent's, though. > > You could also try turning on debug mode for Libevent [with > event_enable_debug_mode(); see the documentation for that function], > which might be able to catch some event-related errors. > > hth, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. > Nick: 1. Thanks for your reply, I was curious if it runs callbacks one at a time, and I guess it does. That eliminates the possibility of a race condition. 2. Yep, I free the timer like so: event_free((*it).second.timeout_timer); whenever I end a connection. 3. I ran the program through valgrind (for almost a week) with no crash. And no memory leaks. It could be coincidence that it didn't crash (the crash is rare and usually under high load), so I might try that again. 4. I want to try debug mode, but where the documentation for it? - David
