Nick,
if I set EVENT_NOEPOLL the offending function (epoll_dispatch) is never
called and transmission-daemon is happily running along.
I put a check for a good events[i].data.ptr into the for loop in
epoll_dispatch and a breakpoint into the else branch that gets executed
if there is a NULL events[i].data.ptr. Here is what I got out of gdb
when it hit the breakpoint:
(gdb) backtrace
#0 epoll_dispatch (base=0x0, arg=0x651e8, tv=0x697c0) at epoll.c:232
#1 0x0003cdc4 in event_base_loop (base=0x65588, flags=0) at event.c:500
#2 0x0001d2d8 in libeventThreadFunc (veh=0x654a8) at trevent.c:182
#3 0x00015590 in ThreadFunc (_t=0x65288) at platform.c:138
#4 0x402780a8 in start_thread (arg=0x6b748) at pthread_create.c:263
#5 0x4033d370 in clone () from /opt/lib/libc.so.6
Backtrace stopped: frame did not save the PC
(gdb) print res
$1 = 3
(gdb) print i
$2 = 2
(gdb) print events[0]
$3 = {events = 4, data = {ptr = 0x697f0, fd = 432112, u32 = 432112, u64
= 17180301296}}
(gdb) print events[1]
$4 = {events = 0, data = {ptr = 0x5, fd = 5, u32 = 5, u64 = 5}}
(gdb) print events[2]
$5 = {events = 432064, data = {ptr = 0x0, fd = 0, u32 = 0, u64 =
1855941267947520}}
(gdb) print *((struct evepoll *)0x697f0)
$7 = {evread = 0x9d400, evwrite = 0x9d448}
(gdb) print *((struct event *)0x9d400)
$8 = {ev_next = {tqe_next = 0x7b1c0, tqe_prev = 0x9c780}, ev_active_next
= {tqe_next = 0x0,
tqe_prev = 0x6b748}, ev_signal_next = {tqe_next = 0x0, tqe_prev =
0x0}, min_heap_idx = 24,
ev_base = 0x65588, ev_fd = 21, ev_events = 2, ev_ncalls = 0,
ev_pncalls = 0x40b98f46, ev_timeout = {
tv_sec = 509311, tv_usec = 387121}, ev_pri = 0, ev_callback =
0x3d8ec <bufferevent_readcb>,
ev_arg = 0x9d400, ev_res = 2, ev_flags = 131}
(gdb) print *((struct event *)0x9d448)
$9 = {ev_next = {tqe_next = 0x0, tqe_prev = 0x713a8}, ev_active_next =
{tqe_next = 0x0, tqe_prev = 0x6b748},
ev_signal_next = {tqe_next = 0x0, tqe_prev = 0x0}, min_heap_idx = 37,
ev_base = 0x65588, ev_fd = 21,
ev_events = 4, ev_ncalls = 1, ev_pncalls = 0x0, ev_timeout = {tv_sec =
509451, tv_usec = 130506}, ev_pri = 0,
ev_callback = 0x3da0c <bufferevent_writecb>, ev_arg = 0x9d400, ev_res
= 4, ev_flags = 139}
It doesn't seem to be a transmission-daemon problem because all the
data, the for loop is operating on comes back from the epoll_wait call
further up the function. It looks like, that function is returning an
array of events that contains some bogus data since already the second
event in the array seems to be bad - not having any flags set in
events[1].events... Could it be a version incompatibility? The kernel
this is running on is quite old (2.6.12).
And here is the svn info output from the directory used to build the
transmission-daemon with:
root#> svn info
Path: .
URL:
http://levent.svn.sourceforge.net/svnroot/levent/branches/patches-1.4/libevent
Repository Root: http://levent.svn.sourceforge.net/svnroot/levent
Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 651
Node Kind: directory
Schedule: normal
Last Changed Author: nprovos
Last Changed Rev: 648
Last Changed Date: 2008-02-17 02:35:24 +0100 (Sun, 17 Feb 2008)
Hope this helps narrowing down the problem.
Frank
Nick Mathewson nickm-at-freehaven.net |libevent| wrote:
On Fri, Feb 22, 2008 at 10:54:57AM +0100, Frank Schaeckermann wrote:
I have installed transmission-daemon (a Bittorrent client) svn revision
5051 on my Maxtor Shared Storage II (ARM little endian) with Linux
2.6.12. Very soon after starting the daemon it segfaults.
Hi, Frank! Here are some things to try:
Does this also happen when you set the EVENT_NOEPOLL environment
variable to disable the epoll method?
Can you post a backtrace from gdb for this?
Does this also happen with libevent 1.3e, or with the libevent 1.4
branch?
Unfortunately, I don't have much way to tell whether this is a
libevent bug or a transmission-daemon bug right now, but it would be
great to help get it fixed either way.
yrs,
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
