Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Alexandre, On 05/06/2024 21:35, Alexandre Rossi wrote: Now that transmission is back in testing, that's an option. Will do if I fin sponsorship for this. I would be happy to sponsor you if you commit to maintaining it long-term (as per the backports rules) -- Martina Ferrari
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > I saw that you just closed this bug a couple of hours ago. Coincidentally, > last night I finally had the time to recompile the package for > bullseye/arm64 and install it on my raspberry pi (I could not use your > backport as it is a different arch). I tested this problem, and I can > confirm that it is effectively fixed. Thanks a lot for you feedback. > PS: It would be great if you could upload the backport to debian too! Now that transmission is back in testing, that's an option. Will do if I fin sponsorship for this. Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi! I saw that you just closed this bug a couple of hours ago. Coincidentally, last night I finally had the time to recompile the package for bullseye/arm64 and install it on my raspberry pi (I could not use your backport as it is a different arch). I tested this problem, and I can confirm that it is effectively fixed. Thanks! PS: It would be great if you could upload the backport to debian too! On 23/04/2024 18:08, Alexandre Rossi wrote: Hi, I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my box running transmission-daemon is on stable.. backporting is straightforward (no change) and I publish[1] a built backport if you want to try. [1] http://deb.zincube.net/ Thanks, Alex -- Martina Ferrari
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my box > running transmission-daemon is on stable.. backporting is straightforward (no change) and I publish[1] a built backport if you want to try. [1] http://deb.zincube.net/ Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, I suppose it must be fixed in 4.x then. Sadly, I cannot test this as my box running transmission-daemon is on stable.. On 12/04/2024 11:01, Alexandre Rossi wrote: Hi, Today I noticed transmission-daemon being down after a reboot, and saw it is crashing with a malloc error. After some debugging, I found out that this only happens if I am using the `--portmap` option *and* a local minissdpd is running. Does this still happen with 4.x? What is the setup to reproduce? $ sudo apt install minissdpd [...] $ /usr/bin/transmission-daemon -f --log-debug --portmap WARN: --log-debug is deprecated. Use --log-level=debug [...] [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 initnatpmp succeeded (0) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 sendpublicaddressrequest succeeded (2) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] inf port-forwarding.cc:215 State changed from 'Not forwarded' to 'Starting' (port-forwarding.cc:215) [...] [2024-04-12 11:57:54.230] dbg port-forwarding-natpmp.cc:42 readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Connexion refusée) (port-forwarding-natpmp.cc:42) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:290 UPNP_GetValidIGD failed: Connexion refusée (111) (port-forwarding-upnp.cc:290) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:291 If your router supports UPnP, please make sure UPnP is enabled! (port-forwarding-upnp.cc:291) [2024-04-12 11:57:54.230] inf port-forwarding.cc:215 State changed from 'Starting' to '???' (port-forwarding.cc:215) [2024-04-12 11:58:02.738] inf session.cc:1328 Transmission version 4.0.5 (a6fe2a64aa) shutting down (session.cc:1328) [...] Closing transmission session... done. ** does not crash ** Thanks, Alex -- Martina Ferrari
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Hi, > Today I noticed transmission-daemon being down after a reboot, and saw it is > crashing with a malloc error. After some debugging, I found out that this only > happens if I am using the `--portmap` option *and* a local minissdpd is > running. Does this still happen with 4.x? What is the setup to reproduce? $ sudo apt install minissdpd [...] $ /usr/bin/transmission-daemon -f --log-debug --portmap WARN: --log-debug is deprecated. Use --log-level=debug [...] [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 initnatpmp succeeded (0) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] dbg port-forwarding-natpmp.cc:38 sendpublicaddressrequest succeeded (2) (port-forwarding-natpmp.cc:38) [2024-04-12 11:57:46.232] inf port-forwarding.cc:215 State changed from 'Not forwarded' to 'Starting' (port-forwarding.cc:215) [...] [2024-04-12 11:57:54.230] dbg port-forwarding-natpmp.cc:42 readnatpmpresponseorretry failed. Natpmp returned -7 (the gateway does not support nat-pmp); errno is 111 (Connexion refusée) (port-forwarding-natpmp.cc:42) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:290 UPNP_GetValidIGD failed: Connexion refusée (111) (port-forwarding-upnp.cc:290) [2024-04-12 11:57:54.230] dbg port-forwarding-upnp.cc:291 If your router supports UPnP, please make sure UPnP is enabled! (port-forwarding-upnp.cc:291) [2024-04-12 11:57:54.230] inf port-forwarding.cc:215 State changed from 'Starting' to '???' (port-forwarding.cc:215) [2024-04-12 11:58:02.738] inf session.cc:1328 Transmission version 4.0.5 (a6fe2a64aa) shutting down (session.cc:1328) [...] Closing transmission session... done. ** does not crash ** Thanks, Alex
Bug#1029162: transmission-daemon: crashes when using --portmap and local minissdpd
Package: transmission-daemon Version: 3.00-1 Severity: normal X-Debbugs-Cc: t...@debian.org Today I noticed transmission-daemon being down after a reboot, and saw it is crashing with a malloc error. After some debugging, I found out that this only happens if I am using the `--portmap` option *and* a local minissdpd is running. $ /usr/bin/transmission-daemon -f --log-debug --portmap malloc(): invalid next size (unsorted) Aborted A GDB backtrace does not show anything interesting: Starting program: /usr/bin/transmission-daemon -f --log-debug --portmap [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0xb60fa1d0 (LWP 3885)] [New Thread 0xb58f91d0 (LWP 3886)] [New Thread 0xb4eff1d0 (LWP 3887)] malloc(): invalid next size (unsorted) Thread 3 "transmission-da" received signal SIGABRT, Aborted. [Switching to Thread 0xb58f91d0 (LWP 3886)] 0xb6b047e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 (gdb) bt #0 0xb6b047e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 #1 0xb6b13a20 in raise () from /lib/arm-linux-gnueabihf/libc.so.6 #2 0xb6b04322 in abort () from /lib/arm-linux-gnueabihf/libc.so.6 #3 0xb6b3c8ae in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) OTOH, Valgrind shows a possible culprit being libminiupnpc, even though that package has not been updated at all (and the program does not crash when run with Valgrind): ==4082== Thread 3: ==4082== Invalid write of size 2 ==4082==at 0x4846474: memcpy (in /usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so) ==4082== Address 0x57d016c is 0 bytes after a block of size 204 alloc'd ==4082==at 0x484063C: malloc (in /usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so) ==4082== ==4082== Invalid write of size 1 ==4082==at 0x4862092: receiveDevicesFromMiniSSDPD (in /usr/lib/arm-linux-gnueabihf/libminiupnpc.so.17) ==4082== Address 0x57d016e is 2 bytes after a block of size 204 alloc'd ==4082==at 0x484063C: malloc (in /usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so) ==4082== ==4082== Invalid write of size 1 ==4082==at 0x48464A8: memcpy (in /usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so) ==4082== Address 0x57d0328 is 0 bytes after a block of size 200 alloc'd ==4082==at 0x484063C: malloc (in /usr/lib/arm-linux-gnueabihf/valgrind/vgpreload_memcheck-arm-linux.so) ==4082== -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (99, 'testing'), (10, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 5.10.0-20-armmp (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-daemon depends on: ii adduser 3.118 ii libc62.31-13+deb11u5 ii libcurl4 7.74.0-1.3+deb11u3 ii libevent-2.1-7 2.1.12-stable-1 ii libminiupnpc17 2.2.1-1 ii libnatpmp1 20150609-7.1 ii libssl1.11.1.1n-0+deb11u3 ii libsystemd0 247.3-7+deb11u1 ii lsb-base 11.1.0 ii transmission-common 3.00-1 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages transmission-daemon recommends: pn transmission-cli transmission-daemon suggests no packages. -- Configuration Files: /etc/transmission-daemon/settings.json [Errno 13] Permission denied: '/etc/transmission-daemon/settings.json' -- no debconf information