Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#1528 closed Bug (fixed)

Transmission segfaults when accessing the web interface (headless build, ARM)

Reported by: tilmanklar Owned by:
Priority: High Milestone: None Set
Component: Transmission Version: 1.51
Severity: Critical Keywords:
Cc:

Description

Hello,

since the build from optware (http://ipkg.nslu2-linux.org/feeds/optware/cs05q3armel/cross/stable/transmission_1.40+r7132-1_arm.ipk) was segfaulting on my ARM-based NAS, I rebuilt the application from sources. Unfortunately, the misbehaviour still persists. Here's what happens when running it in gdb:

sh-2.05b# gdb --args transmission-daemon -f
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi"...
(gdb) handle SIGPIPE nostop noprint nopass
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        No      No              Broken pipe
(gdb) run
Starting program: /opt/bin/transmission-daemon -f
[Thread debugging using libthread_db enabled]
[New Thread 0x403f5000 (LWP 26485)]
[New Thread 0x40bf5520 (LWP 26491)]
Transmission 1.40 (7096) started
Port Forwarding: Opened port 51413 to listen for incoming peer connections
Searching for web interface file "/root/.local/share/transmission/web/javascript/transmission.js"
Searching for web interface file "/opt/share/transmission/web/javascript/transmission.js"
RPC Server: Deflated response from 15116 bytes to 2906
RPC Server: Deflated response from 1406 bytes to 818
RPC Server: Deflated response from 55870 bytes to 16669
RPC Server: Deflated response from 14798 bytes to 3111

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40bf5520 (LWP 26491)]
epoll_dispatch (base=0x0, arg=0x66090, tv=0x6b6d8) at epoll.c:232
232                             evwrite = evep->evwrite;
(gdb) thread apply all bt

Thread 2 (Thread 0x40bf5520 (LWP 26491)):
#0  epoll_dispatch (base=0x0, arg=0x66090, tv=0x6b6d8) at epoll.c:232
#1  0x00048d24 in event_base_loop (base=0x66798, flags=0) at event.c:530
#2  0x0001ca10 in libeventThreadFunc (veh=0x66708) at trevent.c:249
#3  0x0001186c in ThreadFunc (_t=0x6b6d8) at platform.c:123
#4  0x402bc0a8 in start_thread (arg=0x0) at pthread_create.c:263
#5  0x4038b7e0 in clone () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC

Thread 1 (Thread 0x403f5000 (LWP 26485)):
#0  0x4035c574 in nanosleep () from /lib/libc.so.6
#1  0x403851bc in usleep () from /lib/libc.so.6
#2  0x0000ae94 in main (argc=0, argv=0x649f4) at daemon.c:506
232                             evwrite = evep->evwrite;
(gdb)

Since seg faults were also reported in the nas-central forum (http://buffalo.nas-central.org/forums/viewtopic.php?p=95076#p95076), I'm giving this a higher priority/severity.

Tilman

Change History (13)

comment:1 Changed 12 years ago by tilmanklar

BTW, this looks similar to bug #1353 which targets 1.34.

comment:2 Changed 12 years ago by charles

It looks like it's dying in libevent, which doesn't make much sense to me.

Working well on embedded platforms is one of Transmission's main goals, so fixing this would be great. However, I don't have an ARM-based NAS to test with, so I'm not sure where to go with this ticket. A NAS user needs to help track this down.

comment:3 Changed 12 years ago by tilmanklar

I could help you out with this. Just tell me what you need and I would be glad to help with this.

comment:4 Changed 12 years ago by charles

someone in the forums suggested this ... could you try testing this out and see if it does any gooe?

comment:5 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from new to closed

Please reopen if you perform that test or get more information.

comment:6 follow-up: Changed 12 years ago by bitt

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 1.40 to 1.51

I observe the same problem on my ARM based NAS (Western Digital Mybook World Edition - white light version), but only when acccesing with Firefox or Opera. It does not crash when accessed with IE7. At least not until you try to open a torrent. I don't have gdb on my box yet, will try to get a gdb dump.

I couldn't find any libevent on my system, so I assume this is linked statically. I did try setting the enviroment variables as suggested at http://trac.transmissionbt.com/wiki/HeadlessUsage/NSLU2 but did not see any improvement.

comment:7 in reply to: ↑ 6 Changed 12 years ago by charles

Replying to bitt:

I observe the same problem on my ARM based NAS (Western Digital Mybook World Edition - white light version), but only when acccesing with Firefox or Opera. It does not crash when accessed with IE7. At least not until you try to open a torrent. I don't have gdb on my box yet, will try to get a gdb dump.

Yes, I really need a backtrace from a version of Transmission compiled with debugging symbols in order to even get a beginning glimpse of what the problem is. :(

comment:8 Changed 12 years ago by bitt

I get the same backtrace, but there is some other output that might help debug:

~ # /opt/bin/gdb --args transmission-daemon -f


dlopen failed on 'libthread_db.so.1' - libthread_db.so.1: cannot open shared object file: No such file or directory
GDB will not be able to debug pthreads.

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi"...
(gdb) run
Starting program: /root/transmission-daemon -f
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/ld-linux.so.3: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/librt.so.1: warning: sh_link not set for section `.ARM.exidx'
BFD: /opt/lib/libcurl.so.4: warning: sh_link not set for section `.ARM.exidx'
BFD: /opt/lib/libcrypto.so.0.9.8: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/librt.so.1: warning: sh_link not set for section `.ARM.exidx'
BFD: /opt/lib/libcurl.so.4: warning: sh_link not set for section `.ARM.exidx'
BFD: /opt/lib/libcrypto.so.0.9.8: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/libc.so.6: warning: sh_link not set for section `.ARM.exidx'

Program received signal SIG32, Real-time event 32.
0x40301bac in ?? () from /lib/libpthread.so.0
(gdb) c
Continuing.
[22:42:51.146] Couldn't create socket: Address family not supported by protocol
[22:42:51.147] RPC Server: Adding address to whitelist: 127.0.0.1
[22:42:51.149] RPC Server: Serving RPC and Web requests on port 9091
[22:42:51.150] Transmission 1.51 (7970) started
[New LWP 23089]
[22:42:52.152] %s succeeded (%d): initnatpmp succeeded (0)
[22:42:52.153] %s succeeded (%d): sendpublicaddressrequest succeeded (2)
[22:42:58.178] Found Internet Gateway Device "%s": Found Internet Gateway Device "http://192.168.1.1:2869/WANIPConnCtrlUrl"
[22:42:58.178] Local Address is "%s": Local Address is "192.168.1.100"
[22:42:58.196] : Port forwarding through "http://192.168.1.1:2869/WANIPConnCtrlUrl", service "urn:schemas-upnp-org:service:WANIPConnection:1".  (local address: 192.168.1.100:51413)
[22:42:58.197] Starting: Starting
[22:42:58.197] Opened port %d on %s to listen for incoming peer connections: Opened port 51413 on 0.0.0.0 to listen for incoming peer connections
[22:43:33.216] Searching for web interface file "/root/.local/share/transmission/web/javascript/transmission.js"
[22:43:33.216] Searching for web interface file "/opt/share/transmission/web/javascript/transmission.js"

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 23089]
epoll_dispatch (base=0x0, arg=0x84b38, tv=0x82bb0) at epoll.c:232
232     epoll.c: No such file or directory.
        in epoll.c
(gdb) bt
#0  epoll_dispatch (base=0x0, arg=0x84b38, tv=0x82bb0) at epoll.c:232
#1  0x00057d68 in event_base_loop (base=0x7b1b0, flags=0) at event.c:535
#2  0x00023d2c in libeventThreadFunc (veh=0x0) at trevent.c:238
#3  0x00012084 in ThreadFunc (_t=0x82bb0) at platform.c:106
#4  0x402fee84 in ?? () from /lib/libpthread.so.0

First, there's the SIG32. Not sure what that is all about.

Next, it complains about not being able to create socket. I added some breakpoints to find out when it occured:

(gdb) n
[22:18:42.224] Couldn't create socket: Address family not supported by protocol
519     in fdlimit.c
(gdb) info stack
#0  tr_fdSocketCreate (domain=10, type=-1) at fdlimit.c:519
#1  0x0003169c in tr_netBindTCP (addr=0x64e98, port=51413,
    suppressMsgs=1 '\001') at net.c:405
#2  0x00031cb4 in tr_net_hasIPv6 (port=0) at net.c:253
#3  0x00041c3c in tr_sharedInit (session=0x7b580, isEnabled=1 '\001',
    publicPort=51413) at port-forwarding.c:221
#4  0x00015f1c in tr_sessionInitImpl (vdata=0x0) at session.c:536
#5  0x00023bcc in readFromPipe (fd=4, eventType=1, veh=0x7b628)
    at trevent.c:189
#6  0x00057fb4 in event_base_loop (base=0x7b1b0, flags=0) at event.c:392
#7  0x00023d2c in libeventThreadFunc (veh=0x0) at trevent.c:238
#8  0x00012084 in ThreadFunc (_t=0x4002) at platform.c:106
#9  0x402fee84 in ?? () from /lib/libpthread.so.0

If epoll later tries to access this, problems might occur (haven't looked at the code so I'm just throwing things out).

Let me know if you need any other tests.

comment:9 Changed 12 years ago by KyleK

The message about not being able to create a socket is most likely because the NAS doesn't support IPv6. I don't think it has anything to do with the crashes. I see the message too, but I have yet to see my machine crash (Transmission running on a Conceptronic CH3SNAS).

comment:10 Changed 12 years ago by charles

I agree with KyleK that the "not able to create socket" message is unrelated to the crash.

Is there any more information on this? So far all I've seen is that it crashed when thread 2 was polling. This sounds very much like the issues described in this wiki entry but according to Bitt that's not the problem.

comment:11 Changed 12 years ago by bitt

  • Resolution set to fixed
  • Status changed from reopened to closed

Huh... I was sure I already closed this. Sorry about that.

Setting EVENT_NOEPOLL solved the problem. On the wiki it is listed as EVENT_NODEPOLL (extra d in the middle) which is what I tried the first time and obviously that didn't work (assuming it's a typo).

comment:12 Changed 12 years ago by charles

I've fixed the wiki typo. Thanks :)

comment:13 Changed 11 years ago by sim

(deleted spam)

Last edited 11 years ago by charles (previous) (diff)
Note: See TracTickets for help on using tickets.