qbittorrent 5.1.4 libtorrent 1.2.20 REVISION 6 crashes

[mrhotio]

What's wrong?

I've been having a few users that report qbit is crashing upon startup after the revision update from two weeks ago, seems to be on qbit/libtorrent1 rev 6 (however can't rule out rev 1 for qbit/lib2). Going back to the previous commit of my image, which is just rolling back an revision update, so they'll end back on revision 5, seems to solve the issue.

Any idea? From what I recall an revision update is just a new build due to dependency updates...maybe some dependency causing havoc...

Me personally am not seeing those crashes, but I'm only running with one torrent on pause.

Edit: qbit/lib2 also crashes

[userdocs]

Does anyone have a reliable way to reproduce it?

I have not had a chance to look at it yet but being able to reproduce it would really help when I do

[userdocs]

A revision update will be triggered by updated work flow files, which are the deps, but it can pull in an updated musl cross make which could be the problem.

[userdocs]

Maybe they can use these debug builds to test.

https://github.com/userdocs/qbittorrent-nox-static-test/releases/tag/release-5.1.4_v2.0.12
https://github.com/userdocs/qbittorrent-nox-static-test/releases/tag/release-5.1.4_v1.2.20

[mrhotio]

I'll have them test it

[userdocs]

I'm wondering if it's the update from qt6.10 to qt6.11 but since I can't replicate it and don't have any debug info on the issue I can't really say for certain.

If the users can get some debug info it would help.

[Vallaquenta]

Is there a way to contribute to this? I've been running into an issue with this as well, I thought it was Gluetun that was borking things, but after seeing the hotio discussion I think there may be a change behind the screens for qbittorrent that's messing up.

This is the issue with more details on the Gluetun Github: qdm12/gluetun#3260

Is there a way I can help provide additional details?

[userdocs]

you run the debug builds and provide something that can be worked with.

Currenly no reproduction or crash info is available for this issue.

[Vallaquenta]

Using the qbittorrent:test version I'm not getting any connection via Gluetun.

qBittorrent logs:

End alert sequence. Alert: state_update Count: 1
End alert sequence. Alert: session_stats Count: 1
End alert sequence. Alert: state_update Count: 1
End alert sequence. Alert: session_stats Count: 1
End alert sequence. Alert: state_update Count: 1
End alert sequence. Alert: session_stats Count: 1
End alert sequence. Alert: state_update Count: 1
End alert sequence. Alert: session_stats Count: 1
End alert sequence. Alert: state_update Count: 1
End alert sequence. Alert: session_stats Count: 1

Gluetun logs:

2026-04-02T11:53:04+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:53:04+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:53:49+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:53:49+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:54:34+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:54:34+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:55:19+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:55:19+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:56:04+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:56:04+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:56:49+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:56:49+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:57:34+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:57:34+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:58:19+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:58:19+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:59:04+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:59:04+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T11:59:49+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T11:59:49+02:00 DEBUG [port forwarding] port forwarded 57490 maintained
2026-04-02T12:00:34+02:00 DEBUG [port forwarding] refreshing port forward since 45 seconds have elapsed
2026-04-02T12:00:34+02:00 DEBUG [port forwarding] port forwarded 57490 maintained

Is there a more detailed way to get error details than just that one?

[ZoeyBastos]

Hi I'm the user who initially reported the crashing to mrhotio, this is a log from the build (image ghcr.io/hotio/qbittorrent:latest referred hereafter as c1cfba9) that was experiencing issues where you can see the WebUI was continually restarting: https://logs.notifiarr.com/?d92911f592d97f3f#3VAgoZ7fr8TxTXS2yUcD58ppbQ6sAx3oSh6cSK71q2bS

After mrhotio built an image using the provided qbit debug builds (ghcr.io/hotio/qbittorrent:test hereafer referred to as test-c64a5f0) I was able to see the app running without a crash loop but there does seem to be some messages in the logs stating void WebApplication::sessionInitialize() session does not exist!

I span up a new container using test-c64a5f0 where I noticed the above message in the logs and also the torrentsTableDiv element of the webUI was refreshing every few seconds: https://logs.notifiarr.com/?1f16f0ef3368d74d#CivQYd8upuKvyFZ6LA4chohrcmnQ58USFfHg4YbCbuUa)

I also updated/overwrote the initial problem container to test-c64a5f0. I logged in to the WebUI at 16:12:03 after which I did not see a single 'void WebApplication::sessionInitialize() session does not exist!' message (plenty before though). I tried lots of different things, loading all the different tabs, browsing various categories, statuses, tags and trackers as well as stopping and starting torrents. At 16:13:40 I switched to VueTorrent WebUI and carried out the same tests which also did not result in any session errors. I can also see that logging out and sitting on the login page does not cause the session does not exist message to recur: https://logs.notifiarr.com/?0e988fbfbdbc8bb9#u7kyZwu8nwg6vnBcXBDXWKcQQbn15tc78YmPKygqFAq

So in summary test-c64a5f0 build using the qbittorrent debug versions does not seem to have any issues once the app is running and the user logged in. Granted not an extensive test for my part though. Certainly not any constant crash looping as experienced in c1cfba9

[userdocs]

There is nothing really to work with here. I'm expecting core dump / segfaults for the binary but there is nothing to go on yet.

Since the user replaced the v6 with the debug build in the image and no longer has the issue i triggered a rebuild which will release revision v7.

We can see if that resolves with the combination of a new docker image.

@Vallaquenta your issue is unlikely anything to do with this. Your issue seems to be a vpn connection issue. Not a crash. You will need to isolate your issue and open a separate issue if it has anything to do with this build tool and the binary it produces.

[mjtbrady]

In the case that @Vallaquenta reported when using with Gluetun I do not believe that the issue is with the VPN.

Gluetun is attempting to run the script specified with VPN_PORT_FORWARDING_UP_COMMAND variable which is making a qbittorrent API call via 127.0.0.1 using wget. I believe that each call to the API is causing the qbittorrent web UI (and API?) to restart.

I am basing this on the following:

qbittorent logs entries which seem to repeat every time wget makes the API call.

(N) 2026-04-03T15:53:56 - qBittorrent v5.1.4 started. Process ID: 627
(N) 2026-04-03T15:53:56 - Using config directory: /app/qBittorrent/config
(N) 2026-04-03T15:53:56 - Trying to listen on the following list of IP addresses: "10.2.0.2:56674"
(I) 2026-04-03T15:53:56 - Peer ID: "-qB5140-"
(I) 2026-04-03T15:53:56 - HTTP User-Agent: "qBittorrent/5.1.4"
(I) 2026-04-03T15:53:56 - Distributed Hash Table (DHT) support: ON
(I) 2026-04-03T15:53:56 - Local Peer Discovery support: ON
(I) 2026-04-03T15:53:56 - Peer Exchange (PeX) support: ON
(I) 2026-04-03T15:53:56 - Anonymous mode: ON
(I) 2026-04-03T15:53:56 - Encryption support: ON
(I) 2026-04-03T15:53:56 - Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/56674"
(I) 2026-04-03T15:53:56 - Successfully listening on IP. IP: "10.2.0.2". Port: "UDP/56674"
(I) 2026-04-03T15:53:56 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Apr 1 14:46:19 2026.
(N) 2026-04-03T15:53:56 - Using built-in WebUI.
(N) 2026-04-03T15:53:56 - WebUI translation for selected locale (en) has been successfully loaded.
(N) 2026-04-03T15:53:56 - WebUI: Now listening on IP: *, port: 8080

If I manage to get logged into the qbittorrent web UI in between restarts I get kicked out and have to login again.

If I wait to login into the qbittorrent web UI until after the wget command gives up (after the default 20 retries) I do not get kicked out.

If then run the following command (which is what is defined in my gluetun VPN_PORT_FORWARDING_UP_COMMAND variable)

wget -O- --retry-connrefused --post-data "json={\"listen_port\":42000,\"current_network_interface\":\"tun0\","random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences

from within the gluetun (or qbittorrent) container (using docker exec -it gluetun /bin/sh) I am immediately kicked out of the qbittorrent web UI and the above qbittorrent log entries repeat.

This occurs with ghcr.io/hotio/qbittorrent:release-a18530b but not with ghcr.io/hotio/qbittorrent:release-9673f7a.

Hope that that helps as I think that it gives you a way of recreating it?

[userdocs]

So I'm going to post this here as @mjtbrady gave me the most useful lead to start with.

My findings so far.

Download and start the binary, then open a new terminal.

curl -Lo qbt-qt611 https://github.com/userdocs/qbittorrent-nox-static/releases/download/release-5.1.4_v2.0.12/x86_64-qbittorrent-nox
chmod +x qbt-qt611
./qbt-qt611

Then simplest thing to do here is log into web ui and in options/webui bypass auth on localhost for the next command.

wget -O- --post-data='json={"listen_port":41000,"current_network_interface":"eth0","random_port":false,"upnp":false}' http://127.0.0.1:8080/api/v2/app/setPreferences

Which will cause qbt-qt611 to crash.

If you download the same build but using qtbase 6.10.3 it won't crash when you use the api.

curl -Lo qbt-qt610 https://github.com/userdocs/qbittorrent-nox-static-test/releases/download/release-5.1.4_v2.0.12/x86_64-qbittorrent-nox
chmod +x qbt-qt610
./qbt-qt610

The final note of interest is that it will not happen with curl, only wget.

This works fine on qbt-qt611

curl -d 'json={"listen_port":11000,"current_network_interface":"eth0","random_port":false,"upnp":false}' --header 'Referer: http://127.0.0.1:8080' http://127.0.0.1:8080/api/v2/app/setPreferences

So whether or not these two issues are related specifically by this wget issue there seems to be some deliberate change or regression in qtbase 6.11.0 in the network area. Using curl would possibly solve the report glutun issue but not necessarily solve the following issues that would most likely occur.

I spotted some other oddities with libtorrent/utp reported as reason for the crash but this might be due to network issues in qt 6.11

assertion failed. Please file a bugreport at https://github.com/arvidn/libtorrent/issues
Please include the following information:

version: 1.2.20.0-077262424

file: '/home/gh/qbt-build/libtorrent_1.2.20/src/performance_counters.cpp'
line: 98
function: inc_stats_counter
expression: value >= 0 || c >= num_stats_counters

stack:
<not supported>
assertion failed. Please file a bugreport at https://github.com/arvidn/libtorrent/issues
Please include the following information:

version: 1.2.20.0-077262424

file: '/home/gh/qbt-build/libtorrent_1.2.20/src/performance_counters.cpp'
line: 98
function: inc_stats_counter
expression: value >= 0 || c >= num_stats_counters

stack:
<not supported>

Thread 18 "x86_64-qbittorr" received signal SIGABRT, Aborted.
[Switching to LWP 271]
0x00007ffff6e07165 in __restore_sigs ()
(gdb) bt
#0  0x00007ffff6e07165 in __restore_sigs ()
#1  0x00007ffff6e071c1 in raise ()
#2  0x0000000000000000 in ?? ()
(gdb)

assertion failed. Please file a bugreport at https://github.com/arvidn/libtorrent/issues
Please include the following information:

version: 1.2.20.0-077262424

file: '/home/gh/qbt-build/libtorrent_1.2.20/src/utp_stream.cpp'
line: 2497
function: ack_packet
expression: <unconditional>

stack:
<not supported>

Thread 2 "x86_64-qbittorr" received signal SIGABRT, Aborted.
[Switching to LWP 274]
0x00007ffff6e07165 in __restore_sigs ()
(gdb) bt
#0  0x00007ffff6e07165 in __restore_sigs ()
#1  0x00007ffff6e071c1 in raise ()
#2  0x0000000000000000 in ?? ()
(gdb)

At this point I can't say for certain what the specific issue is. I think it will require a bug report on the qt bug tracker to identify the cause.

If rebuilding with qt 6.10.3 solves this for everyone that is what i'll do for now. I'm the only person who used v6.11.0 so this is probably why it's only this build that has the issue.

6.10.2 https://pkgs.alpinelinux.org/packages?name=qt6*&branch=edge
6.10.2 https://vcpkg.io/en/package/qtbase.html

Please test these non debug builds built against 6.10.3

https://github.com/userdocs/qbittorrent-nox-static-test/releases/tag/release-5.1.4_v1.2.20