imkaihao
commented
4 years ago Same problem here with qBittorrent 4.2.3 and macOS Catalina 10.15.4
Open kquinsland opened 4 years ago
imkaihao
commented
4 years ago Same problem here with qBittorrent 4.2.3 and macOS Catalina 10.15.4
ghost
commented
2 years ago Issue was reported on a very old version. If anyone still experiencing this please comment to reopen or create a new ticket.
briankendall
commented
1 year ago Commenting because me and a friend still experience this issue with recent versions of qBittorrent. We were just discussing it and how incredibly annoying it is, since it takes down our home server every time it happens, and I decided to see if I could find a bug report here for this issue. Would someone please re-open it?
We're running version 4.4.5. (Haven't updated to 4.5.0 just yet.) We trigger it under essentially the same circumstances that @kquinsland says: multiple torrents downloading at high speeds.
The only additional information I can offer is that limiting the number of simultaneous connections that qBittorrent makes seems to mitigate -- but not solve -- the issue. Currently I have qBittorrent set to only download one torrent at a time with 20 max connections per torrent, which has been pretty stable. But every now and then I'll do something like force-start a few extra torrents, and sometimes that takes my whole system down!
(I wonder if this is an underlying issue in libtorrent?)
briankendall
commented
1 year ago I can reproduce this issue very, very reliably using a virtual machine. In the latest qBittorrent I tried queuing up fourteen Linux ISO torrents, selected for being several gigabytes in size and having many seeds. I have a gigabit fiber internet connection, so my download speeds can easily reach 60-70 MB/s. If I set qBittorrent's connection limit to be 50 connections per torrent and 500 connections globally, queue up these torrents, and then start them all simultaneously, then the entire system will crash within about ten seconds!
The crash happens easily in Mojave and Catalina. However, I can't get it to happen in Big Sur. My thoughts are that this is a bug in macOS that gets triggered by there being lots of network connections all with high throughput. Somehow the connections get into a degenerate state where they lock up and prevent the process from quitting, and then any process that tries to establish a new network connection will lock up as well. Apple may have fixed it in Big Sur.
In any case, it seems unlikely that the root cause of this bug is in qBittorrent. Maybe it's in libtorrent somehow. But if it is fixed in Big Sur then there's probably not much to be done about it.
For those of us (like me) who are still using earlier versions of macOS, I recommend setting the max number of global connections to somewhere between 100-200 to avoid this crash. I'm not 100% sure that prevents it from happening completely, but so far I've had good luck with those numbers.
xavier2k6
commented
1 year ago @briankendall I'm going to re-open this....can ty provide any crash report, analytic data etc.?
kquinsland
commented
1 year ago I can reproduce this issue very, very reliably using a virtual machine. In the latest qBittorrent I tried queuing up fourteen Linux ISO torrents, selected for being several gigabytes in size and having many seeds. I have a gigabit fiber internet connection, so my download speeds can easily reach 60-70 MB/s. If I set qBittorrent's connection limit to be 50 connections per torrent and 500 connections globally, queue up these torrents, and then start them all simultaneously, then the entire system will crash within about ten seconds!
It's been a few years since I was a macOS user, but this more or less matches my experience.
The crash happens easily in Mojave and Catalina. However, I can't get it to happen in Big Sur. My thoughts are that this is a bug in macOS that gets triggered by there being lots of network connections all with high throughput. Somehow the connections get into a degenerate state where they lock up and prevent the process from quitting, and then any process that tries to establish a new network connection will lock up as well. Apple may have fixed it in Big Sur.
In any case, it seems unlikely that the root cause of this bug is in qBittorrent. Maybe it's in libtorrent somehow. But if it is fixed in Big Sur then there's probably not much to be done about it.
I never was able to prove it but did suspect this might be the case! Some of the system behaviors that would present just before the hard crash included gimped file and network IO in other programs. E.G.: switching over to an old chrome tab that had since been suspended or doing a file copy across the network.
If there was a problem in libtorrent or similar, it would be hard to explain how that would effect chrome as well unless there was a problem in something they both share; the net/file IO from the OS.
I am happy to see that the issue isn't present (for you) in macOS 11.x branches and - assuming you're using the same version of qBittorrent/libtorrentin each of the VMs - is another data point pointing at something in macOS.
briankendall
commented
1 year ago @briankendall I'm going to re-open this....can ty provide any crash report, analytic data etc.?
This is quite hard to do, because the entire system starts locking up once the crash happens. Not every process stops working, but most do. I think it affects any of those that try to open a socket, but that's just a guess.
I might be able to produce a sample of qBittorrent, if I can get it to complete. Is there anything else about the system state that might be useful?
briankendall
commented
1 year ago @xavier2k6 I managed to get a sample of qBittorrent when the crash has occurred. There's no debugging info in the app though so someone would have to symbolicate it.
I have taken the time to omit certain personal details in the provided log and screenshots. Great care was taken to make sure the omissions do not hinder technical details, however.
qBittorrent version and Operating System
I am running OSX Catalina (Stable), fully patched as of posting. Likewise, all connected devices and peripherals have Up To Date firmware (as of posting)
My physical hardware:
See the attached screenshot for qBit torrent and library versions:
What is the problem
I can reliably get OSX to lock up and then crash / reboot when qBittorrent has many torrents in an Active/Downloading state or there is otherwise high CPU usage from qBittorrent.
The first few times that the crash happened, i thought it was a random fluke event. Around the third crash, I started to notice similarities in symptoms and began to actually research the stack trace that OSX presented on login after the reboot. The key bit from each crash is:
The numbers are different each time, but the
monitored services unresponsiveis consistent. When first looking for other OSX errors related towatchdogdI found a few users that mentioned external monitors and docking stations... which wasn't helpful as I can reproduce this crash with no external monitor or docking station attached. Other than the power cord, the only devices I have attached are a USB3 hub which has both a USB NIC and a USB hard drive attached.When I changed the gigabit USB NIC out for a 10/100 NIC, I had multiple hours of stability... which was my clue that there's something about the hard limits of a 10/100 USB NIC that keeps system state under whatever threshold results in a crash.
I was able to do some additional testing with a Thunderbolt 3 attached intel NIC; limiting qBittorrent to around
20MiB/sseems to keep things stable-ish. Going much beyond that, though, will only shorten the time until the next crash event.That's about as far as I've gone to narrow down the issue... it's not conclusive, but my gut + what i see in
Console.appreally does indicate that qBittorrent is hitting some limits that brings OSX down.What is the expected behavior
I would expect that qBitotrrent uses resources as best it can but does not risk system stability to do so.
Steps to reproduce
I am orders of magnitude more familiar with GNU/Linux system internals than I am with xnu/bsd internals... so please bear with me if this isn't a super rigorous reproduction method. I am open to any feedback about how to better / more precisely measure OSX and qBittorrent to provide more detail!
/dev/nullor similar may also work.You may need less throughput on a system with fewer compute/memory resources, but I do not have any older OSX machines that I can test that on.
Have as many active torrents as needed to achieve 30+ MB/s of throughput going. Configure qBitotrrent so that all torrents seed indefinitely once downloaded.
Wait. I have found that increasing the load on the system (e.g. 20+ Chrome tabs or some other ram heavy application idle in background) can hasten the crash. I have not been able to consistently trigger it, but I have found that placing a bursty load on the system usually does. E.G.: From a crash/reboot, decline to open all applications that were open and start only qBittorrent. Close all apps that launch by default on login. Then, launch a Chrome session and, when prompted, restore the 15+ tabs that were open. If you do this while qBittorrent is still in the process of scanning the partial downloads trying to figure out where it left off before the crash, another crash is imminent.
However, the system will also crash when left "alone" and with no significant load. That is: all applications except for qBittorrent are closed. System is plugged in and power settings are configured so that the screen may turn off but the system may not enter sleep so long as the unit it plugged in. Unfortunately, I don't know how long this takes as the system is usually unattended and I come back to it to find that it's powered off or at the login/unlock screen.
You'll know a crash is imminent because things in the background freeze / stop updating, but the foreground application seems/looks responsive. E.G.: The 'badge' on the qBitotrrent icon in the Dock will stop updating the download speed, but I can still scroll through the list of torrents loaded in qBittorrent. I can still scroll through the foreground Chrome tab, but refreshing the tab or clicking any link or opening a new tab will fail. In some cases, applications will display a 'classic' OSX style loading circle as if they're waiting for some process to render the content that should be in their window. This usually indicates that a crash is imminent.
While drafting this post, i've kept a very close eye on transfers. I've set the throttle to about 20 MiB/s in the down direction and haven't had a crash in the hour or so it's taken to draft this. I have had several moments when my cursor would freeze and keystrokes would take several seconds to appear as the fans on this macbook spin up, however. This same behavior is usually the initial indicator that further instability is around the corner, but because of the throttle, i've managed to keep the system up.
Extra info(if any)
See attached for the number of
Spin Reports. I believe this is OSX parlance for "beach balls"... a 100% accurate predictor that a crash and reboot is imminentI believe my issue is related to, but those tickets are not well documented, so it's hard to be sure.
https://github.com/qbittorrent/qBittorrent/issues/12118 https://github.com/qbittorrent/qBittorrent/issues/12111
Main application:
Here is the full
qbittorrent_2020-03-06-111432_$MyHostName.cpu_resource(as shown in screenshots)Here is the full
qbittorrent_2020-03-08-100700_$MyHostName.wakeups_resource(as shown in screenshots):