Opened 13 years ago

Closed 13 years ago

#1384 closed Bug (invalid)

Transmission crashes in uClibc environment doing verify

Reported by: eddie89 Owned by: charles
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.42+
Severity: Normal Keywords:
Cc:

Description

Hi there. I have some problems.

I have transmission-1.34 on gentoo-uclibc (uclibc-0.9.28).

To get it working i have to do many tricks:

1) In background it doesn't open ports. It doesn't work.

2)To work around this, I have to launch it with -f option. It starts, open web port and hangs. (I get timeout from browser opening web interface)

3)To get it really start, i have to type "Ctrl+Z" (send it SIGSTOP), then bg or fg (to send it SIGCONT) to get it really started.

4)Now web interface works, but adding torrents makes it crash (see error below).

5)Restarting it ( points 2 & 3), it load the torrent and start sharing :D.

6)Verifying a torrent makes it crash. (I had to delete resume files)

Now I tried to uncheck the "Start transfers when added" option, and I could add a torrent, but when I start the download, i get from the console (strace):

nanosleep({1, 0}, (torrent): Couldn't read resume file
(torrent): Queued for verification
(torrent): Verifying torrent
0xbfa4d0d4)           = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGRT_1 (Unknown signal 33) @ 0 (0) ---
wait4(1428, NULL, __WCLONE, NULL)       = 1428
_exit(0)

So I think that a problem is related to the verification process (beside the problem of foreground).

Change History (13)

comment:1 Changed 13 years ago by charles

Does gdb work on uclibc?

If so, could you get a backtrace of the crash?

Also, is there a way to use uclib for just transmission, inside a regular Linux box, for testing this, via preload or ld library path or some other mechanism?

comment:2 Changed 13 years ago by eddie89

gdb works on uclibc. I'll get a backtrace.

You can install uclibc beside glibc as I know, but maybe you need a gcc compiler like i386-gentoo-linux-uclibc-gcc (like cross-compiling), I don't know if glibc-gcc can link uclibc.

(I don't know how to use gdb, sorry.)

comment:3 Changed 13 years ago by charles

I've just been working through some of the uclibc pages, and built uclibc on my Linux box, and got an error message much like this one. If I'm understanding this response correctly, I'd basically need to build an entire mini-distro in order to make this work correctly. If that's the case, I'd rather use the debugging information provided by you. ;)

If you need help with gdb, just ask. Also if you drop by the transmission irc channel there's usually someone there who can help, and that may have a faster turnaround time than trac.

comment:4 Changed 13 years ago by charles

This ticket is currently in limbo. It's probably not going to get fixed unless a uClibc user steps up to the plate to track down the crash, or walks me through getting a toolchain built on Fedora s.t. I can try to debug it there.

The ideal would be a patch and a note that says "this fixes it", though. ;)

comment:5 Changed 13 years ago by coolphoenix

i'm using libtransmission compiled with uclib for my webinterface - so i'm not sure whether this is the same scenario like eddi89 has. and since i did not write that webinterface from the beginning (and it's a very messy code...), i don't know whether there is something to prevent the mentioned errors.

but one thing i find in the code are those lines (transmissiond.c)

114	static void sigHandler       ( int signal );

715	        signal( SIGINT, sigHandler );
716	        signal( SIGTERM, sigHandler );
717	        signal( SIGHUP, sigHandler );

and finally

1459 static void sigHandler( int signal )
1460	{

1463	    switch( signal )
1464	    {
1465	        case SIGTERM:
1466	        case SIGINT:
1467	        case SIGHUP:

1468-1526 // DO SOME STUFF, SHUTDOWN TORRENTS, ETC

1527	        default:
1528	            break;
1529	    }

i'm not sure whether this is related to this "signal-problem" eddi89 has - maybe you should give it a try. it looks like the usual sighandler is simply overwritten by one ignoring everything but 3 signals "SIGINT", "SIGHUP" and "SIGTERM" and not exiting on an unknown signal.

comment:6 Changed 13 years ago by charles

regarding comment 5: transmissiond.c is not part of our codebase. That needs to be reported to the webtransmission.enlightened.de people.

So we're still stuck. I would be happy to help however I can, but this ticket is going to require a uClibc user steps up to track down the crash or walk me through getting a toolchain built on Fedora s.t. I can try to debug it there.

The ideal would be a patch and a note that says "this fixes it", though. ;)

comment:7 Changed 13 years ago by coolphoenix

my comment 5 was not about a bug in transmissiond.c (i'm developing it on btw) but about the bug is not there in transmissiond.c. since transmissiond is compiled with uclibc and it works, the snipped of codes i posted might be the solution to the problem here, but i don't know exactly.

someone has to test it in transmission

comment:8 Changed 13 years ago by charles

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

coolphoenix: thanks for the clarification.

Still, this ticket is going to continue to languish until a uClibc user tracks down the crash. None of the Transmission team use uClibc and there's not enough information in this ticket to continue.

I'd be happy to get this bug fixed, but I'm not going to knock myself out building a uClibc toolchain and environment when nobody else is even providing backtraces or other information.

To whom it may concern, please reopen this ticket when more information is available.

comment:9 Changed 13 years ago by seledka

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 1.34 to 1.42+

Hi all. Don't know if this is the same issue or anoter one... I'm running Transmission 1.50b4 on ARM926EJ box with uclib-0.9.28. Steps to reproduce:

1) I have a .torrent file which seems to be valid in other torrent apps. I put it to /root/.config/transmission-daemon/torrents.
2) transmission-daemon crashes immidiatly after startup with following output:

[root@Storage torrents]# transmission-daemon -f
Couldn't create socket: Address family not supported by protocol
RPC Server: Adding address to whitelist: 127.0.0.1
RPC Server: Adding address to whitelist: 192.168.1.*
RPC Server: Serving RPC and Web requests on port 9091
RPC Server: Whitelist enabled
Transmission 1.50b4 (7815) started
FM09 Vanilla: Couldn't read resume file
Segmentation fault

  1. Trying to debug with gdb:

[root@Storage torrents]# gdb transmission-daemon
This GDB was configured as "arm-linux-uclibc"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) set args -f
(gdb) show args
Argument list to give program being debugged when it is started is "-f".
(gdb) run
Starting program: /usr/local/bin/transmission-daemon -f
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 990)]
Couldn't create socket: Address family not supported by protocol
RPC Server: Adding address to whitelist: 127.0.0.1
RPC Server: Adding address to whitelist: 192.168.1.*
RPC Server: Serving RPC and Web requests on port 9091
RPC Server: Whitelist enabled
Transmission 1.50b4 (7815) started
FM09 Vanilla: Couldn't read resume file
[New Thread 2049 (LWP 993)[New Thread 1026 (LWP 994)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 990)]
0x000273d4 in generateKeyParam (msg=0xfa8e3 "", len=10) at tracker.c:1004[[BR]] 1004 *msg++ = pool[tr_cryptoRandInt( poolSize )];
(gdb) backtrace

0x000273d4 in generateKeyParam (msg=0xfa8e3 "", len=10) at tracker.c:1004 0x000276dc in tr_trackerNew (torrent=0xf8ac0) at tracker.c:1060 0x0001dd18 in torrentRealInit (session=0x87d60, tor=0xf8ac0, ctor=0xf38a8) at torrent.c:534 0x0001e168 in tr_torrentNew (session=0x87d60, ctor=0xf38a8, setmeError=0x0) at torrent.c:619 0x00019764 in tr_sessionLoadTorrents (session=0x87d60, ctor=0xf38a8, setmeCount=0x0) at session.c:952 0x0000baf0 in main (argc=2, argv=0xbef80a74) at daemon.c:281

If you need any additional info, feel free to contact me.

comment:10 Changed 13 years ago by charles

seledka: thanks very much for the backtrace. I've checked in a possible fix for this... could you please upgrade to r7870 or higher and let me know if it still crashes? And if it does, could you attach another backtrace?

comment:11 Changed 13 years ago by charles

seledka: ping

comment:12 Changed 13 years ago by charles

seledka: ping

comment:13 Changed 13 years ago by charles

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

closing this ticket due to lack of information.

feel free to reopen this ticket when more information is available.

Note: See TracTickets for help on using tickets.