Re: [Libevent-users] assert in http.c

[Myk Taylor <myk002@xxxxxxxxx>]

Hi all,

I've done a bit more debugging on this, and after reproducing a few 
segfaults (different from the original assert), it seems like the 
problem is related to the issues Zhuang Yuyao was having a year and a 
half ago:

http://archives.seul.org/libevent/users/Jun-2010/msg00002.html

It is the same situation for me: I am using openssl bufferevents and 
BEV_OPT_DEFER_CALLBACKS is set.  I am also beset with warnings like:

Epoll MOD(4) on fd 471 failed.  Old events were 6; read change was 2 
(del); write change was 0 (none): Bad file descriptor

However those warnings are not always coincidental with a segfault. 
Here is a representative backtrace:

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff7ba1449 in evbuffer_free (buffer=0x7afee0) at buffer.c:568
#2  0x00007ffff7ba5dc2 in _bufferevent_decref_and_unlock 
(bufev=0x7b38a0) at bufferevent.c:629
#3  0x00007ffff7b9cb4b in event_process_deferred_callbacks 
(breakptr=0x71b530, queue=0x71b558) at event.c:1364
#4  event_process_active (base=<optimized out>) at event.c:1403
#5  event_base_loop (base=0x71b450, flags=<optimized out>) at event.c:1589
#6  0x000000000040380e in main (argc=8, argv=0x7fffffffd6b8) at ...

frame 0 is due to the lock callback being null in EVLOCK_LOCK.  I note 
that all the segfaults I have cores for involve 
event_process_deferred_callbacks().

Could it be that the openssl bufferevent isn't canceling pending 
callbacks when it is destroyed?  Alternately, are there assumptions 
about when a bufferevent can be destroyed that I am violating?

Thanks,
Myk Taylor

On 01/17/12 00:32, Myk Taylor wrote:
> I sometimes trigger the
> EVUTIL_ASSERT(req != NULL);
> line in evhttp_connection_fail() in http.c while running a load test
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.