qBittorrent frequently maxes out one CPU logical processor when VPN enabled and/or after OS sleep and resume

[OnceIWasCool]

qBittorrent version and Operating System

• qBittorrent v4.1.6 (64-bit) (but has reproduced on several previous versions)
• Installed using installer
• Library versions: Qt: 5.12.2, Libtorrent: 1.1.13.0, Boost: 1.70.0
• Windows 10 Pro 10.0.18362 Build 18362

What is the problem

Approximately once every two or three times that the PC goes to sleep, upon resume, qBittorrent maxes out one of the CPU cores. This high CPU usage continues until qBittorrent is closed and restarted (i.e. it's not a transient issue that only occurs for a short period of time after the OS resume).

2019-09-10 EDIT: This appears related to turning on a VPN; sleep/resume may be a red herring. See this post for more info.

What is the expected behavior

qBittorrent CPU usage remains constant after sleep and resume (excepting any resume-specific tasks).

Steps to reproduce

1. Start qBittorrent. I have several torrents active; I have not tried to reproduce this without any active torrents, as I have ratios to maintain. :-)
2. Allow the PC to suspend itself / put itself to sleep.
3. Wake/resume the PC.
4. Check qBittorrent CPU usage.
5. If qBittorrent CPU usage is normal, repeat Steps 2-4.

Extra info(if any)

This appears to be the same bug as #7104 ("High CPU usage after sleep"). That bug was closed with the comment "If this still happens for you, please open a new ticket and include as many details as possible." I'm happy to provide more detail and/or run tests on my machine, but I'm not sure what would be useful, so instead of preemptively spamming a bunch of information, I'll instead do my best to respond to any/all questions asked here.

Once qBittorrent is in this state, the high CPU usage persists until the app is restarted.

This problem has reproduced for me for months (and, judging by #7104, may have existed for years).

Most recent three log files attached. (qbittorrent.log.bak24 and qbittorrent.log.bak23 were renamed to qbittorrent.log.bak24.log and qbittorrent.log.bak24.log, respectively, so that GitHub would accept them as attachments.)

qbittorrent.log
qbittorrent.log.bak24.log
qbittorrent.log.bak23.log

[GuillaumeLescure]

Maybe I will say the obvious but the project really need to fix thoses performances issues.

I checked the GitHub issues of the project just because my computer almost crashed thanks to qBittorrent. My Manjaro has just boot and after 10-15mn on the web all my PC was over-slow. My CPU and my HDD were at their rupture point. And just, after removing 3 "old" torrents that were seeding, all came back to normal.

This kind of bug is an hardware killer for God sake ! I uninstall softwares for less than that !

You have 22 opened performance issue and some are more than 5 years old ... You need to clean thoses issues and prioritize them over featuring or refactoring. I use qBittorrent since many years but I didn't see a lot of bugfix or performance improvement over the years. It's really sad to see that much work (commits and PR) and so few results 😢

[MrAureliusR]

Maybe I will say the obvious but the project really need to fix thoses performances issues.

I checked the GitHub issues of the project just because my computer almost crashed thanks to qBittorrent. My Manjaro has just boot and after 10-15mn on the web all my PC was over-slow. My CPU and my HDD were at their rupture point. And just, after removing 3 "old" torrents that were seeding, all came back to normal.

This kind of bug is an hardware killer for God sake ! I uninstall softwares for less than that !

You have 22 opened performance issue and some are more than 5 years old ... You need to clean thoses issues and prioritize them over featuring or refactoring. I use qBittorrent since many years but I didn't see a lot of bugfix or performance improvement over the years. It's really sad to see that much work (commits and PR) and so few results

You are more than welcome to contribute to the project yourself. qBittorrent is fully maintained by volunteers. The way things get done is people having the time and motivation to work on them.

[Seeker2]

I wonder if this is related to the broken 127.0.0.1 local loopback listening connections being closed that caused 100% cpu core usage.

[xavier2k6]

#9965 (comment)

[Piccirello]

@OnceIWasCool Could you run qBittorrent with strace (or the Windows equivalent of strace)? I'd be curious to see what it's doing when it resumes from sleep.

[OnceIWasCool]

Rather unsatisfying update...

@OnceIWasCool Could you run qBittorrent with strace (or the Windows equivalent of strace)? I'd be curious to see what it's doing when it resumes from sleep.

I went to my PC to do this using Process Monitor (a Windows equivalent to strace). Usually, when I unlock my PC, if qBittorrent had been running in the meantime, it would show 13% CPU usage as described above (13% system CPU usage = 100% usage of one CPU core), but this time CPU usage was low/normal. I suspended and resumed the PC seven times, but each time CPU usage remained below 2% at all times.

This suggests one of three things to be the case:

1. The PC needs to sit for a while before qBittorrent starts hogging CPU,

2. The problem happens when the PC initiates sleep, but not when the user initiates sleep, or

3. qBittorrent 4.1.7 fixed the problem (I upgraded since I filed the bug).

The next time I notice high qBittorrent CPU usage I'll attach Process Monitor and see what it's up to, although I recognize that's not as good as catching it in the transition from normal to high CPU usage.

[OnceIWasCool]

Ok, got it to reproduce by starting a new download and then suspending and resuming while that download was underway. I started Process Monitor before suspending (when CPU usage was normal) and stopped it after resuming (when CPU usage was spiked).

I've attached Process Monitor logs in all three available formats. The dialog to save as XML had options for saving stack data as well -- I don't know if that means the XML file has information the other two don't, or if the other two file formats include stack data by default.

Take a look and let me know if that helps at all.

qBittorrent CPU usage.zip

[OnceIWasCool]

Dump of qBittorrent in its high-CPU-usage state attached -- the TID of the thread consuming all the CPU is 3152.

qbittorrent dump - TID 3152.zip

[Seeker2]

OnceIWasCool, since you've run Process Explorer...have you also tried TCP View to see if the listening ports qBitTorrent randomly opens at start are closed after OS sleep and resume?

I know forcing them closed using TCP View causes 100% CPU usage on 1 core, but that might "naturally" occur after OS sleep and resume as well.

[OnceIWasCool]

I'd be happy to run TCP View, but I'm going to need some help interpreting the results, or someone's going to have to tell me what log files to save and share here.

[Seeker2]

Look for qbittorrent.exe LISTENING on multiple ports -- with some of those ports being consecutive numbers of each other...and the in and out ports are reversed on them.

[OnceIWasCool]

Looks like no? See screenshot attached.

[Seeker2]

Probably not, going by your screenshot.
But just to be certain, can you check again with Resolve Addresses disabled AND Show Unconnected Endpoints enabled?

I don't expect to see anything on your end...
...but I'm still seeing consecutive ports on mine (qBT v4.1.7 32bit) on ip address 127.0.0.1 -- and I forgot, they weren't in Listening mode, they were ESTABLISHED connections instead.

I found other qBT issues on github possibly related to the ips connected-to-self:
#10791
#5663

[OnceIWasCool]

Attached. Two screenshots because there was more than one screen of output.

[OnceIWasCool]

ALSO, probably more importantly: after taking my last set of screenshots, I killed the app and restarted it to get its CPU usage back to normal. Its CPU usage was still normal when I woke the machine this morning to take the shots posted immediately above.

I turned on my VPN (Windscribe), and qBittorrent immediately maxed out one of my CPU cores. I turned of Windscribe, but the CPU usage is still pegged. I wonder if this is a separate issue, or if what I thought was a resume/suspend issue was really a VPN issue that I wasn't noticing until I resumed my machine. I'd previously done at least a dozen suspend/resumes trying unsuccessfully to get the issue to reproduce; it seems that suspend/resume alone is not enough to trigger it.

Title and original bug description both updated.

[Seeker2]

When I break the 127.0.0.1 local loopback connections (using TCP view, which sends RSTs to them) qBitTorrent makes to itself, one of my CPU virtual cores maxes out as well.
First mention of 127.0.0.1 issue at qBT forums:
https://qbforums.shiki.hu/index.php/topic,3982.msg23615.html#msg23615

Turning on/off your VPN (or using a killswitch) probably breaks the 127.0.0.1 connections as well.

You would only see the 127.0.0.1 connections with a fresh start of qBitTorrent before it starts showing the high CPU usage.

Your screenshots also show what I call listen port hell:
arvidn/libtorrent#2020

[ghost]

I faced the same problem with Windscribe VPN. If I chose to forcefully close all TCP sockets and enabled killswitch qBt would constantly utilize a core to the max. Maybe @arvidn can give us some input abt whats going on.

[arvidn]

as far as I can tell, this is an issue in asio. I filed a report (with a patch I think fixes it), here.

anyone distributing binaries could apply that patch when building (@sledgehammer999 wink wink)

[xavier2k6]

"Fixed" in asio 1.16.1 which is included in Boost 1.73

TEST BUILD

[FranciscoPombal]

@OnceIWasCool @An0n666 can you please try the build linked in #11039 (comment)? It uses Boost 1.73 which includes the fix resulting from the report posted by arvidn (#11039 (comment))

[ghost]

@FranciscoPombal
Tested. Issue seem to have been resolved.

[FranciscoPombal]

@An0n666

Thanks for confirming. It's pretty much a given that next stable version will be shipped with Boost >= 1.73 on Windows (they are usually compiled with whatever most recent Boost version is available at the time), so this can be considered resolved. In the meantime, users can use a build such as the one linked above.