# Transmission exited on signal 11 (core dumped)



## nugged (Dec 13, 2014)

FreeBSD 9.1-RELEASE-p19, transmission-daemon-2.82_1

After some "magic" (yep, updating ports) transmission starts to die without any useful info. Just cores.

Checked all rights for folders and files, all OK, even rebuild all ports again... no luck.

If I clean it's working directories, it starts, until first .torrent file in watched directory appears.
Then it moves that file to own transmission/home/torrents and even creates .resume file, ... and crashes.

No help from gdb and .core file.

Any run with that info what was in that subdirectories before port updating also crashes it.

No help from log also:

`su -m transmission -c "/usr/local/bin/transmission-daemon -g /usr/local/etc/transmission/home -f -O --log-debug"`


```
[2014-12-13 22:15:58.728 EET] Transmission 2.84 (14307) started (session.c:736)
[2014-12-13 22:15:58.728 EET] Couldn't read "/usr/local/etc/transmission/home/stats.json": No such file or directory (utils.c:233)
[2014-12-13 22:15:58.728 EET] Couldn't read "/usr/local/etc/transmission/home/stats.benc": No such file or directory (utils.c:233)
[2014-12-13 22:15:58.728 EET] Cache Maximum cache size set to 256.0 MiB (16384 blocks) (cache.c:261)
[2014-12-13 22:15:58.728 EET] RPC Server Adding address to whitelist: 127.0.0.1 (rpc-server.c:824)
[2014-12-13 22:15:58.728 EET] RPC Server Serving RPC and Web requests on port 127.0.0.1:9091/transmission/ (rpc-server.c:1033)
[2014-12-13 22:15:58.728 EET] RPC Server Whitelist enabled (rpc-server.c:1037)
[2014-12-13 22:15:58.728 EET] RPC Server Password required (rpc-server.c:1040)
[2014-12-13 22:15:58.728 EET] Bound socket 9 to port 61390 on 0.0.0.0 (net.c:379)
[2014-12-13 22:15:58.728 EET] Using settings from "/usr/local/etc/transmission/home" (daemon.c:557)
[2014-12-13 22:15:58.728 EET] Saved "/usr/local/etc/transmission/home/settings.json" (variant.c:1214)
[2014-12-13 22:15:58.728 EET] Saved pidfile "/var/run/transmission/daemon.pid" (daemon.c:569)
[2014-12-13 22:15:58.728 EET] transmission-daemon requiring authentication (daemon.c:577)
[2014-12-13 22:15:58.728 EET] Watching "/var/transm/DropIn" for new .torrent files (daemon.c:595)
[2014-12-13 22:15:58.728 EET] Using readdir to watch directory "/var/transm/DropIn" (watch.c:161)
[2014-12-13 22:15:58.728 EET]  Read resume file "/usr/local/etc/transmission/home/resume/-SOME-FILE-.0a0c7a5431a31ab1.resume" (resume.c:721)
[2014-12-13 22:15:58.728 EET] -SOME-FILE- Resume file found 15 files marked for download (resume.c:155)
[2014-12-13 22:15:58.728 EET] Loaded 1 torrents (session.c:1992)
[2014-12-13 22:15:58.728 EET] Port Forwarding (NAT-PMP) initnatpmp succeeded (0) (natpmp.c:70)
[2014-12-13 22:15:58.728 EET] Port Forwarding (NAT-PMP) sendpublicaddressrequest succeeded (2) (natpmp.c:70)

Segmentation fault (core dumped)
```


----------



## robert1307 (Dec 13, 2014)

What does backtrace show?
`gdb transmission-daemon
core transmission-daemon.core
backtrace`


----------



## nugged (Dec 13, 2014)

`gdb /usr/local/bin/transmission-daemon transmission-daemon.core`


```
(gdb) backtrace
#0  0x0000000802326dcc in strcmp () from /lib/libc.so.7
#1  0x000000080165c5b0 in lh_doall_arg () from /lib/libcrypto.so.6
#2  0x000000080165c936 in lh_insert () from /lib/libcrypto.so.6
#3  0x0000000801614ebd in OBJ_NAME_add () from /lib/libcrypto.so.6
#4  0x00000008027f0a15 in SSL_library_init () from /usr/local/lib/libssl.so.8
#5  0x0000000801322383 in curl_slist_free_all () from /usr/local/lib/libcurl.so.7
#6  0x00000008012fb439 in curl_global_init () from /usr/local/lib/libcurl.so.7
#7  0x000000000041dbfe in dht_hash ()
#8  0x00000000004080a2 in ?? ()
#9  0x0000000802010f03 in pthread_getprio () from /lib/libthr.so.3
#10 0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fffff7fc000
```


----------



## manas (Dec 20, 2014)

I'm seeing some segmentation faults with transmission-daemon. gdb doesn't produce anything useful:


```
#0  0x0000000800e9fca5 in ?? ()
#1  0x0000467700000000 in ?? ()
#2  0x0000000000000000 in ?? ()
```

I've turned on logging but haven't seen anything in the logs yet.

Here's something more substantial:

```
#0  0x0000000800e9fca5 in UTP_ProcessIncoming () from /usr/local/lib/libutp.so.0
#1  0x0000000800ea13d2 in UTP_IsIncomingUTP () from /usr/local/lib/libutp.so.0
#2  0x000000000041814a in dht_random_bytes ()
#3  0x0000000000417f49 in dht_random_bytes ()
#4  0x00000008010b4256 in event_base_loop () from /usr/local/lib/libevent-2.0.so.5
#5  0x0000000000418c48 in dht_random_bytes ()
#6  0x000000000040858f in ?? ()
#7  0x0000000801d874f5 in pthread_create () from /lib/libthr.so.3
#8  0x0000000000000000 in ?? ()
```

I'm running this on FreeBSD 10.1, the common line in our backtraces seems to be libthr.so.3.

Backtrace when transmission-daemon is built with `make WITH_DEBUG=yes STRIP= install clean`


```
#0  0x0000000800e9efe7 in UTPSocket::selective_ack () from /usr/local/lib/libutp.so.0
Cannot access memory at address 0xf5110000f51a
```


----------



## fulano (Dec 23, 2014)

I had the same problem last year with transmission-qt4-2.82 . The only solution was install from the pkg. The gtk version always worked flawlessly, by the way.


----------



## manas (Dec 23, 2014)

Yeah, net-p2p/transmission-daemon doesn't have a GUI. It has a web UI though.


----------



## NewGuy (Dec 27, 2014)

I am running into a similar problem. I installed net-p2p/transmission-daemon from packages (running on FreeBSD 10.1 64-bit) and the daemon crashes about once per day with a signal 11. Sometimes the daemon runs for a minute, sometimes it runs for a day or two. But it always dies with a signal 11 and no other sign of anything going wrong.


----------



## manas (Dec 29, 2014)

I have contacted the port maintainer crees (crees@FreeBSD.org) about it. He has not responded about a fix yet, he must be working on it.
NewGuy, could you compile net-p2p/transmission-daemon with `make WITH_DEBUG=yes STRIP= install clean` and let it run until it crashes. Then you should have a transmission-daemon.core in your home directory. Run the following commands:

```
gdb transmission-daemon
core transmission-daemon.core
backtrace
```
and post the output. I expect that it will be similar if not the same to mine, it might help the port maintainer to pin down the problem.


----------



## MrStalker (Jan 1, 2015)

I have the same problem...
net-p2p/transmission-daemon 2.84

```
root@Eviko:/home/mrstalker # gdb transmission-daemon
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) core transmission-daemon.core
warning: core file may not match specified executable file.
Core was generated by `transmission-daemon'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libminiupnpc.so.10...done.
Loaded symbols for /usr/local/lib/libminiupnpc.so.10
Reading symbols from /usr/local/lib/libnatpmp.so.1...done.
Loaded symbols for /usr/local/lib/libnatpmp.so.1
Reading symbols from /usr/local/lib/libdht.so.0...done.
Loaded symbols for /usr/local/lib/libdht.so.0
Reading symbols from /usr/local/lib/libutp.so.0...done.
Loaded symbols for /usr/local/lib/libutp.so.0
Reading symbols from /usr/local/lib/libevent-2.0.so.5...done.
Loaded symbols for /usr/local/lib/libevent-2.0.so.5
Reading symbols from /usr/local/lib/libcurl.so.4...done.
Loaded symbols for /usr/local/lib/libcurl.so.4
Reading symbols from /lib/libcrypto.so.7...done.
Loaded symbols for /lib/libcrypto.so.7
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/libssl.so.7...done.
Loaded symbols for /usr/lib/libssl.so.7
Reading symbols from /usr/lib/libgssapi.so.10...done.
Loaded symbols for /usr/lib/libgssapi.so.10
Reading symbols from /usr/lib/libgssapi_krb5.so.10...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.10
Reading symbols from /usr/lib/libheimntlm.so.11...done.
Loaded symbols for /usr/lib/libheimntlm.so.11
Reading symbols from /usr/lib/libkrb5.so.11...done.
Loaded symbols for /usr/lib/libkrb5.so.11
Reading symbols from /usr/lib/libhx509.so.11...done.
Loaded symbols for /usr/lib/libhx509.so.11
Reading symbols from /usr/lib/libcom_err.so.5...done.
Loaded symbols for /usr/lib/libcom_err.so.5
Reading symbols from /usr/lib/libasn1.so.11...done.
Loaded symbols for /usr/lib/libasn1.so.11
Reading symbols from /usr/lib/libwind.so.11...done.
Loaded symbols for /usr/lib/libwind.so.11
Reading symbols from /usr/lib/libheimbase.so.11...done.
Loaded symbols for /usr/lib/libheimbase.so.11
Reading symbols from /usr/lib/libroken.so.11...done.
Loaded symbols for /usr/lib/libroken.so.11
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /usr/lib/private/libheimipcc.so.11...done.
Loaded symbols for /usr/lib/private/libheimipcc.so.11
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0000000800001aeb in ?? ()
[New Thread 8048d6c00 (LWP 100130/transmission-daemon)]
[New Thread 804406800 (LWP 100091/transmission-daemon)]
[New Thread 804406400 (LWP 100062/transmission-daemon)]
(gdb) backtrace
#0  0x0000000800001aeb in ?? ()
#1  0x000002ef0444d790 in ?? ()
#2  0x0000000000000000 in ?? ()
```


----------



## manas (Jan 23, 2015)

No idea what's going on with this. The port maintainer has not responded to any of my emails.


----------



## Naesstrom (Jan 25, 2015)

I'm running Transmission 2.84_1 on FreenasFreeNAS 9.3 and I'm getting the same problem. FreenasFreeNAS just shutting down with Code 10 or sometimes 11.
I started a thread over at the freenasFreeNAS forums but got a suggestion that you had the same problem over here.
https://forums.freenas.org/index.php?threads/transmission-exiting-on-signal-11-10.26123/


----------



## manas (Jan 27, 2015)

I have submitted the bug to the bugzilla: Issue 197125


----------



## jasmine (Jan 28, 2015)

net-p2p/transmission-cli and slaves regressed on CVE-2012-6129 after transmission-2.74 because of
r369657. This was fixed by r377674 and r378009. Only transmission-* 2.84_1 were vulnerable, crashes with 2.82_1 could be another bug if they still happen on 2.84.

So, try the usual procedure:

update ports
reinstall net/libutp
restart transmission-* apps


----------



## manas (Jan 28, 2015)

jasmine said:


> net-p2p/transmission-cli and slaves regressed on CVE-2012-6129 after transmission-2.74 because of
> r369657. This was fixed by r377674 and r378009. Only transmission-* 2.84_1 were vulnerable, crashes with 2.82_1 could be another bug if they still happen on 2.84.
> 
> So, try the usual procedure:
> ...



Looks like I updated the net/libutp some time back. I am going to reinstall net-p2p/transmission-daemon and see if the issue persists.


----------



## fulano (Jan 28, 2015)

Installed transmission-qt-2.84 on a 10.1-RELEASE i386 machine today. All ports updated. No issues until now.


----------



## Vladimir Grebenschikov (Feb 13, 2015)

Still failed for me on SSL initialization, by some reason it uses SSL from libcrypto (not openSSL):

```
srv# pkg info transmission-web transmission-daemon openssl miniupnpc bittorrent-libutp libnatpmp curl libevent2 dht
transmission-web-2.84
transmission-daemon-2.84_1
openssl-1.0.1_18
miniupnpc-1.9
bittorrent-libutp-0.20130514_1
libnatpmp-20140401
curl-7.40.0
libevent2-2.0.22_1
dht-0.22

srv# uname -a
FreeBSD srv.fbsd.ru 9.3-STABLE FreeBSD 9.3-STABLE #1 r271608: Mon Sep 15 11:06:18 MSK 2014     root@srv:/usr/obj/usr/src/sys/SRV  amd64

srv# gdb transmission-remote
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) r -l
Starting program: /usr/local/bin/transmission-remote -l
[New LWP 101847]
[New Thread 804007400 (LWP 101847/transmission-remote)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 804007400 (LWP 101847/transmission-remote)]
0x00000008023712dc in strcmp () from /lib/libc.so.7
(gdb) bt
#0  0x00000008023712dc in strcmp () from /lib/libc.so.7
#1  0x00000008016992d0 in lh_doall_arg () from /lib/libcrypto.so.6
#2  0x0000000801699656 in lh_insert () from /lib/libcrypto.so.6
#3  0x00000008016518dd in OBJ_NAME_add () from /lib/libcrypto.so.6
#4  0x0000000802618d15 in SSL_library_init () at ssl_algs.c:77
#5  0x00000008013599d3 in curl_slist_free_all () from /usr/local/lib/libcurl.so.4
#6  0x00000008013328c1 in curl_global_init () from /usr/local/lib/libcurl.so.4
#7  0x0000000801332918 in curl_easy_init () from /usr/local/lib/libcurl.so.4
#8  0x000000000040b6d1 in tr_curl_easy_init (writebuf=0x8040230c0) at remote.c:1757
#9  0x000000000040b917 in flush (rpcurl=0x80401b040 "localhost:9091/transmission/rpc/", benc=0x7fffffffe7b0) at remote.c:1795
#10 0x000000000040c302 in processArgs (rpcurl=0x80401b040 "localhost:9091/transmission/rpc/", argc=2, argv=0x7fffffffe928) at remote.c:2016
#11 0x000000000040db14 in main (argc=2, argv=0x7fffffffe928) at remote.c:2434
(gdb)
```


----------



## Vladimir Grebenschikov (Feb 13, 2015)

```
srv# ldd /usr/ports/net-p2p/transmission-daemon/work/transmission-2.84/daemon/transmission-remote
/usr/ports/net-p2p/transmission-daemon/work/transmission-2.84/daemon/transmission-remote:
    libminiupnpc.so.10 => /usr/local/lib/libminiupnpc.so.10 (0x8008a5000)
    libnatpmp.so.1 => /usr/local/lib/libnatpmp.so.1 (0x800ab0000)
    libdht.so.0 => /usr/local/lib/libdht.so.0 (0x800cb2000)
    libutp.so.0 => /usr/local/lib/libutp.so.0 (0x800ebb000)
    libevent-2.0.so.5 => /usr/local/lib/libevent-2.0.so.5 (0x8010c4000)
    libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x801307000)
    libcrypto.so.6 => /lib/libcrypto.so.6 (0x80156f000)   <<<< SSL from libcrypto (crash was while initialization of openssl under libcurl)
    libz.so.6 => /lib/libz.so.6 (0x801916000)
    libm.so.5 => /lib/libm.so.5 (0x801b2a000)
    libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x801d4b000)
    libthr.so.3 => /lib/libthr.so.3 (0x802047000)
    libc.so.7 => /lib/libc.so.7 (0x80226a000)
    libssl.so.8 => /usr/local/lib/libssl.so.8 (0x8025c8000)   <<<< SSL from openssl
    libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x802831000)
    libgssapi_krb5.so.10 => /usr/lib/libgssapi_krb5.so.10 (0x802a3b000)
    libheimntlm.so.10 => /usr/lib/libheimntlm.so.10 (0x802c55000)
    libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x802e5a000)
    libhx509.so.10 => /usr/lib/libhx509.so.10 (0x8030cb000)
    libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x80330c000)
    libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x80350e000)
    libasn1.so.10 => /usr/lib/libasn1.so.10 (0x803905000)
    libroken.so.10 => /usr/lib/libroken.so.10 (0x803b89000)
    libcrypt.so.5 => /lib/libcrypt.so.5 (0x803d9b000)
```


----------



## Vladimir Grebenschikov (Feb 13, 2015)

```
# gdb work/transmission-2.84/daemon/transmission-remote
GNU gdb 6.1.1 [FreeBSD]
...
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) r -l
Starting program: /usr/ports/net-p2p/transmission-daemon/work/transmission-2.84/daemon/transmission-remote -l
[New LWP 101013]
[New Thread 804007400 (LWP 101013/transmission-remote)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 804007400 (LWP 101013/transmission-remote)]
0x00000008023718bc in strcmp () from /lib/libc.so.7
(gdb) bt
#0  0x00000008023718bc in strcmp () from /lib/libc.so.7
#1  0x0000000801699820 in getrn (lh=0x8040233c0, data=0x804088e00, rhash=<value optimized out>) at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/lhash/lhash.c:431
#2  0x0000000801699ba6 in lh_insert (lh=0x8040233c0, data=0x804088e00) at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/lhash/lhash.c:189
#3  0x0000000801651b7d in OBJ_NAME_add (name=0x0, type=2, data=0x8038fbca0 "\223\003") at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/o_names.c:203
#4  0x0000000802618d15 in SSL_library_init () at ssl_algs.c:77
#5  0x00000008013599e3 in curl_slist_free_all () from /usr/local/lib/libcurl.so.4
#6  0x00000008013328d1 in curl_global_init () from /usr/local/lib/libcurl.so.4
#7  0x0000000801332928 in curl_easy_init () from /usr/local/lib/libcurl.so.4
#8  0x000000000040b6d1 in tr_curl_easy_init (writebuf=0x8040230c0) at remote.c:1757
#9  0x000000000040b917 in flush (rpcurl=0x80401b040 "localhost:9091/transmission/rpc/", benc=0x7fffffffe740) at remote.c:1795
#10 0x000000000040c302 in processArgs (rpcurl=0x80401b040 "localhost:9091/transmission/rpc/", argc=2, argv=0x7fffffffe8b8) at remote.c:2016
#11 0x000000000040db14 in main (argc=2, argv=0x7fffffffe8b8) at remote.c:2434

(gdb) fr 3
#3  0x0000000801651b7d in OBJ_NAME_add (name=0x0, type=2, data=0x8038fbca0 "\223\003") at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/objects/o_names.c:203
203        ret=(OBJ_NAME *)lh_insert(names_lh,onp);

>>>> name=0x0 looks incorrect

(gdb) fr 4
#4  0x0000000802618d15 in SSL_library_init () at ssl_algs.c:77
77    ssl_algs.c: No such file or directory.
    in ssl_algs.c
(gdb)

>>>> whole libcrypto build with debug info, sources in right place
>>>> looks like ssl_algs.o from openssl?
```


----------



## Vladimir Grebenschikov (Feb 13, 2015)

Problem can be workarounded if build libcurl with GNUTLS instead of OpenSSL:

```
# cat /var/db/ports/ftp_curl/options | egrep 'GNUTLS|OPENSSL'
_FILE_COMPLETE_OPTIONS_LIST=CA_BUNDLE COOKIES CURL_DEBUG DEBUG DOCS EXAMPLES HTTP2 IDN IPV6 LDAP LDAPS LIBSSH2 PROXY RTMP TLS_SRP GSSAPI_BASE HEIMDAL_PORT KRB5_PORT CARES THREADED_RESOLVER CYASSL GNUTLS NSS OPENSSL POLARSSL
OPTIONS_FILE_SET+=GNUTLS
OPTIONS_FILE_UNSET+=OPENSSL
```


----------



## kpa (Feb 14, 2015)

Vladimir Grebenschikov said:


> problem can be workarounded if build libcurl with GNUTLS instead of OpenSSL
> 
> # cat /var/db/ports/ftp_curl/options | egrep 'GNUTLS|OPENSSL'
> _FILE_COMPLETE_OPTIONS_LIST=CA_BUNDLE COOKIES CURL_DEBUG DEBUG DOCS EXAMPLES HTTP2 IDN IPV6 LDAP LDAPS LIBSSH2 PROXY RTMP TLS_SRP GSSAPI_BASE HEIMDAL_PORT KRB5_PORT CARES THREADED_RESOLVER CYASSL GNUTLS NSS OPENSSL POLARSSL
> ...



Can you show us your /etc/make.conf? I suspect that you're mixing the base system OpenSSL with the OpenSSL from ports and that is the source of the problem with net-p2p/transmission-daemon. The way it should be is that if you use the ports version of OpenSSL even in one port you should then make every other port that uses OpenSSL use the port version as well.

Rumour is that for FreeBSD 12 the base system OpenSSL will be hidden from ports by moving it into the private libraries that are not available for direct linking outside the base system. This would mean that all ports using OpenSSL would automatically use the ports version of OpenSSL and problems like this wouldn't be possible.


----------



## François Charlier (Apr 8, 2015)

I can confirm the issue with transmission-daemon-2.84_2 build today with OpenSSL both from the system or from ports, similar backtrace as in answer #19 in this thread.
Compiling curl with GnuTLS prevents transmission-daemon from crashing.


----------



## NewGuy (Apr 9, 2015)

I recompiled the curl port yesterday with the GnuTLS option enabled and OpenSSL disabled. (I did not re-build transmission-daemon.) Since then the Transmission has been running without any crashes. I'm hoping this fixes the problem.

The crashes appear to be a fault in curl. Has anyone filed a PR against it? If not I'll send one in.


----------



## kpa (Apr 9, 2015)

NewGuy said:


> I recompiled the curl port yesterday with the GnuTLS option enabled and OpenSSL disabled. (I did not re-build transmission-daemon.) Since then the Transmission has been running without any crashes. I'm hoping this fixes the problem.
> 
> The crashes appear to be a fault in curl. Has anyone filed a PR against it? If not I'll send one in.



The problem is well known but the fix is not going to be a simple one since it's architectural level design problem in the ports system, see this thread:

http://lists.freebsd.org/pipermail/freebsd-ports/2015-April/098651.html


----------

