On Fri, Dec 7, 2012 at 3:20 PM, Vargas, Christina
<christina.var...@interoptechnologies.com> wrote:
>
> Has anyone seen a backtrace like this before? We have an application designed
> to handle SMPP traffic over TCP, but I am not permitted to disclose source
> code. It is using libevent-2.0.12, but not setting the base event (old style
> libevent).
>
> (gdb) bt full
> #0 event_base_loop (base=0x8dfa3b8, flags=0) at event.c:2152
> n = 1
> evsel = (const struct eventop *) 0x841100
> tv = {tv_sec = 0, tv_usec = 19436}
> tv_p = <value optimized out>
> res = <value optimized out>
> retval = <value optimized out>
> __func__ = "event_base_loop"
> #1 0x0080ef59 in event_loop (flags=0) at event.c:1486
> No locals.
One thing I'd suggest is seeing if you can reproduce using the latest
version of 2.0: that's 2.0.21-stable. There have been a bunch of
bugfixes since 2.0.12-stable. None of them remind me of this case,
but it's possible that it is one of them.
If you haven't tried running in debug mode yet, I'd suggest it: just
call event_enable_debug_mode() before other any other libevent
functions, and see if it logs any errors.
If that doesn't help, it would also be interesting to see the real
call-stack at this point: line 2152 is in event_del_internal, not in
event_base_loop. I'm guessing that this is the one in
timeout_process, but I'm not too sure. You can get this information
by compiling libevent with the -fno-inline compiler flag to prevent
inlining. With that information, it would also be very help to see
the contents of *ev and *ev->ev_base.
best of luck,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
