transmission-daemon crashing on ARM linux

[spaceman_spiff]

Hey Guys,

I have been having troubles with transmission crashing randomly on my Synology DS210j. I have tried various versions and they all eventually crash. I am currently running 1.83 build 10040 which I downloaded and compiled today. Sometimes I get an exciting message such as this:

"*** glibc detected *** transmission-daemon: double free or corruption (!prev): 0x00259c38 *** Aborted (core dumped)

but other times it just says "segmentation fault".

How might I provide more information about this crash? I might try running in gdb so i can get a call stack trace...

Cheers.

[Jordan]

getting a backtrace via gdb would be great. Thanks for offering.

[LevellerDK]

I have the same problem, with transmission crashing randomly. I'm running transmission-daemon 1.80-1 installed via ipkg on my Synology DS210j.

I don't know where (if at all) transmission-daemon logs errors, but if someone can point me in the right direction, I will of cause happily post the trace log.

Thanks!

[spaceman_spiff]

Okay.. This doesn't look too helpful but here we go:

*** glibc detected *** /opt/bin/transmission-daemon: free(): invalid next size (fast): 0x001f4198 ***

Program received signal SIGABRT, Aborted.
0x4032b4cc in raise () from /lib/libc.so.6

#0 0x4032b4cc in raise () from /lib/libc.so.6
#1 0x4032cc9c in abort () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC


---
I'll try again and see what happens..

[tiprya]

Getting the same crash on my Synology - running 1.80 (most up to date package on ipkg).

Let me know how I can help with error reports.

[spaceman_spiff]

Getting the same crash on my Synology - running 1.80 (most up to date package on ipkg).

Let me know how I can help with error reports.

Maybe something in this thread will be helpful. Check out the last post in thread.

Yep.. that is pretty much what I had to go through to compile and install the latest nightly build. I also had to mess around with libpthread versions to get it to link properly. Unfortunately the crash still occurs as above.

Looks like some sort of memory corruption problem. I wonder if one of the optware libs is somehow subtly incompatible? This crash does not seem to happen other platforms as far as i have read on forums... If it did i think people would be louder.

[grzegorzdubicki]

Hi, I have apparently similar problem with Transmission 1.83 from binary SPK package got from here at my Synology DS210j.

And I have had the same problem just before that upgrade (which was the reason I did the upgrade) with 1.80 from ipkg binary package from NSLU2 optware feed.

I have just filed a bug in Transmission tracker about it.

Please contribute to it if you get more info than I did or let me know how can I get more info about it myself (how do you get those messages in the syslog? I've got just some tracker and hash info from transmission there even with highest message level..).

[Jordan]

syslog probably won't help. What we really need is a backtrace from gdb, please.

[spaceman_spiff]

syslog probably won't help. What we really need is a backtrace from gdb, please.

I ran it in gdb and the call stacks did not look very useful. See my post above.

I am currently trying out version 1.77 and i have not encountered the issue. I have been running for 3 or four hours and usually it crashes before 20 min are up.

[rb07]

If it helps, its not the ARM, is not Linux, seems to be specific to your Synology environment. I've ran all released versions on my HP MediaVault which is also ARM/Linux (armv5tejl/2.6.12.6 to be precise).

To get meaningful debug info you need to build with debug enabled, and that should include the libraries ideally.

I'm using a lot of non-original libraries, either built them myself or from Optware:

Code: Select all

$ /lib/ld-linux.so.3 --list /opt/bin/transmission-daemon
        libevent-1.4.so.2 => /opt/lib/libevent-1.4.so.2 (0x40006000)
        libcurl.so.4 => /opt/lib/libcurl.so.4 (0x40023000)
        libidn.so.11 => /opt/lib/libidn.so.11 (0x40076000)
        libssh2.so.1 => /opt/lib/libssh2.so.1 (0x400b2000)
        libldap-2.3.so.0 => /opt/lib/libldap-2.3.so.0 (0x400e7000)
        librt.so.1 => /opt/lib/librt.so.1 (0x40122000)
        libssl.so.0.9.8 => /opt/lib/libssl.so.0.9.8 (0x4013e000)
        libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x40183000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x402b3000)
        libz.so.1 => /opt/lib/libz.so.1 (0x402be000)
        libm.so.6 => /opt/lib/libm.so.6 (0x402cf000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x4037d000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x4038f000)
        libc.so.6 => /lib/libc.so.6 (0x403a8000)
        liblber-2.3.so.0 => /opt/lib/liblber-2.3.so.0 (0x404bd000)
        libresolv.so.2 => /opt/lib/libresolv.so.2 (0x404d0000)
        libsasl2.so.2 => /opt/lib/libsasl2.so.2 (0x404e9000)
        libssl.so.0.9.7 => /opt/lib/libssl.so.0.9.7 (0x40507000)
        libcrypto.so.0.9.7 => /opt/lib/libcrypto.so.0.9.7 (0x4053c000)
        /lib/ld-linux.so.3 (0x2a000000)

Only the loader and libc are from the original software installed (and I been trying to get rid of that libc).

[spaceman_spiff]

If it helps, its not the ARM, is not Linux, seems to be specific to your Synology environment. I've ran all released versions on my HP MediaVault which is also ARM/Linux (armv5tejl/2.6.12.6 to be precise).

To get meaningful debug info you need to build with debug enabled, and that should include the libraries ideally.

I'm using a lot of non-original libraries, either built them myself or from Optware:

Code: Select all

$ /lib/ld-linux.so.3 --list /opt/bin/transmission-daemon
        libevent-1.4.so.2 => /opt/lib/libevent-1.4.so.2 (0x40006000)
        libcurl.so.4 => /opt/lib/libcurl.so.4 (0x40023000)
        libidn.so.11 => /opt/lib/libidn.so.11 (0x40076000)
        libssh2.so.1 => /opt/lib/libssh2.so.1 (0x400b2000)
        libldap-2.3.so.0 => /opt/lib/libldap-2.3.so.0 (0x400e7000)
        librt.so.1 => /opt/lib/librt.so.1 (0x40122000)
        libssl.so.0.9.8 => /opt/lib/libssl.so.0.9.8 (0x4013e000)
        libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x40183000)
        libdl.so.2 => /opt/lib/libdl.so.2 (0x402b3000)
        libz.so.1 => /opt/lib/libz.so.1 (0x402be000)
        libm.so.6 => /opt/lib/libm.so.6 (0x402cf000)
        libgcc_s.so.1 => /opt/lib/libgcc_s.so.1 (0x4037d000)
        libpthread.so.0 => /opt/lib/libpthread.so.0 (0x4038f000)
        libc.so.6 => /lib/libc.so.6 (0x403a8000)
        liblber-2.3.so.0 => /opt/lib/liblber-2.3.so.0 (0x404bd000)
        libresolv.so.2 => /opt/lib/libresolv.so.2 (0x404d0000)
        libsasl2.so.2 => /opt/lib/libsasl2.so.2 (0x404e9000)
        libssl.so.0.9.7 => /opt/lib/libssl.so.0.9.7 (0x40507000)
        libcrypto.so.0.9.7 => /opt/lib/libcrypto.so.0.9.7 (0x4053c000)
        /lib/ld-linux.so.3 (0x2a000000)

Only the loader and libc are from the original software installed (and I been trying to get rid of that libc).

Hmm.. thanks for the info. My environment looks quite different. Here are the libs I am currently using for my (working) 1.77 install:

Code: Select all

> /lib/ld-linux.so.3 --list /opt/bin/transmission-daemon
        libnsl.so.1 => /opt/lib/libnsl.so.1 (0x40001000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4001d000)
        libcurl.so.4 => /opt/lib/libcurl.so.4 (0x40037000)
        libz.so.1 => /opt/lib/libz.so.1 (0x40077000)
        libssl.so.0.9.8 => /opt/lib/libssl.so.0.9.8 (0x40090000)
        libcrypto.so.0.9.8 => /opt/lib/libcrypto.so.0.9.8 (0x400d6000)
        libdl.so.2 => /lib/libdl.so.2 (0x4020c000)
        libm.so.6 => /lib/libm.so.6 (0x40217000)
        libc.so.6 => /lib/libc.so.6 (0x402c6000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x403f6000)
        librt.so.1 => /lib/librt.so.1 (0x40416000)
        /lib/ld-linux.so.3 (0x2a000000)

I wonder what it is that is causing me the trouble. Also, it is strange that only the newer versions crash.

[grzegorzdubicki]

Have you seen this comment from Transmission devs? Can anyone here build Transmission using those tips and test that solution? - I don't have a working build environment so I can't..

[rb07]

Good point grzegorzdubicki, but you don't need a development environment to test it: just set the environment variable before running the daemon...

Code: Select all

export EVENT_NOEPOLL=1

Which is standard procedure with my NAS and many other NASes, libevent is known not to work 100% (I do have a developer environment and libevent 1.4.11 fails in just one of its checks, haven't tried the latest stable 1.4.13 or the 2.0 series alpha).

But that doesn't seem relevant to this post, it would be the same with all versions of Transmission.

[grzegorzdubicki]

Good point grzegorzdubicki, but you don't need a development environment to test it: just set the environment variable before running the daemon...

Code: Select all

export EVENT_NOEPOLL=1

Which is standard procedure with my NAS and many other NASes, libevent is known not to work 100% (I do have a developer environment and libevent 1.4.11 fails in just one of its checks, haven't tried the latest stable 1.4.13 or the 2.0 series alpha).

But that doesn't seem relevant to this post, it would be the same with all versions of Transmission.

I am trying that, thanks for the tip. I'll let know if it helped.

PS I've got libevent 1.4.13.

[tiprya]

Running with -f flag gives this when it crashes:

Code: Select all

*** glibc detected *** transmission-daemon: free(): invalid next size (fast): 0x00327280 ***
Segmentation fault (core dumped)