mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
qBt 4.6.2 crashes on Arch Linux (stops when changing to libtorrent v2) #15392
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#15392
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @BuckeyeCoder on GitHub (Jan 16, 2024).
qBittorrent & operating system versions
qBittorrent v4.6.2 (64-bit) (but actually 4.6.2-2, see below)
From the Help > About clippy
NeoFetch
What is the problem?
qBittorrent randomly crashes about 3x per 24 hour period. After reading several other issue reports here, the following seems relevant to say:
Crash report from
journalctl:Steps to reproduce
This issue is intermittent and seemingly random.
Additional context
Log(s) & preferences file(s)
BTW, the instructions on this page say to look for
qBittorrent.logbut on Arch Linux anyway its little "b" as inqbittorrent.log. I don't use the "Watched Folders" feature. I have the other two requests however:qbittorrent.log
qBittorrent.conf
@HanabishiRecca commented on GitHub (Jan 17, 2024):
I don't see the cause here, like
SIGSEGVor something.Are you sure the client is not simply OOM killed? You can lookup it in the journal/dmesg.
@BuckeyeCoder commented on GitHub (Jan 18, 2024):
Its possible, not sure how to answer. The rig has 128GB of ram so its not going to run out of memory that way, but is the program only allocated so much by the OS and it could OOM by exceeding its allocation?
I ask because I found something interesting; the connection had a misconfiguration. In the "Advanced" section the network interface was bound to a VPN while at the same time in the "Connection" section a proxy was also setup. I didn't realize both methods were active at the same time. Since I have removed the proxy and kept the VPN bound, I haven't experienced a crash. That might be luck or not enough testing time has past.
Even if the crash is solved, it seems like there should be some logging added here in this situation to help debug. I intend to keep testing and I'll report back.
@adem4ik commented on GitHub (Jan 21, 2024):
I have Manjaro & qBittorrent from the official repos seems unstable as shit: random crashes, random freezes, zombie process, it even blocks system restart and corrupts my NTFS' disks. I guess the main problem is Libtorrent v2.
That's why I've switched to AUR's versions, especially to Libtorrent v1. Currently I have this and this installed.
@BuckeyeCoder commented on GitHub (Jan 23, 2024):
I'm going to call this crashing issue "solved", but leave it to the maintainers to decide if this issue should be closed just yet. I think the solution raises a couple more issues.
After many days of observing stable performance, I am certain that my previous answer definitely contains the source of the crashing. The only thing I have to add is that IPv6 was disabled on this box which seems to have created a circular situation where IPv6 access is continually being requested and denied.
Before closing this issue, consider if the lessons learned here might impact logging or design, specifically:
It took a long time to diagnose this. Please consider making a couple changes.