force terminating sockets results in high cpu usage

[senposage]

Please provide the following information

qBittorrent version and Operating System

qbittorrent 4.04 windows 10 pro 1709

What is the problem

if you use TCPView or a vpn that force terminates sockets to prevent leaks and terminate bittorrents TCP sockets qbittorrent starts consuming 30 to 40% more cpu time then normal

What is the expected behavior

qbittorrent should recover from the socket closure and correctly handle the unexpected socket closure

Steps to reproduce

Download TCPview https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview terminate qbittorrent.exes 's socket

Extra info(if any)

(type here)

[Syst3mSh0ck]

When would you practically need to force terminate the socket? I can't see this being an issue.

[senposage]

thats what I thought but some vpn software does it to prevent IP leaks (windscribe) it completely breaks the tcp stack and is not something it should be doing but I went back and forth with windscribe over it they insist on it being a security thing, I partially agree with them, in the qbt should handle such cases better than it does and not burn a bunch of cpu time trying to connect to a non existent socket, qbt isn't alone in this behavior either APC,plex,acronis also don't like it when you force term sockets which again is in violation of the TCP spec edit: this may qualify as a libtorrent issue @libtorrent

[yegors]

Windscribe dev here. We terminate all TCP sockets on tunnel up, as they can keep sending data over the original default gateway, instead of the tunnel.

[Seeker2]

I've observed the same behavior quite some time back with qBT v3.3.13 using libtorrent 1.0.11.0 on an ancient Win XP SP3 box... and also Deluge v1.3.15 using libtorrent 1.0.11.0 on the same computer: https://github.com/arvidn/libtorrent/issues/2020#issuecomment-312477329

This might also occur for sleep and hibernate modes that completely shut down the network adapter.

[senposage]

fixing this may close some other non-related issues as well because its gonna require qbittorrent to reload the interface and sockets on ip change

https://github.com/qbittorrent/qBittorrent/issues/6495 https://github.com/qbittorrent/qBittorrent/pull/8159 https://github.com/qbittorrent/qBittorrent/issues/8258 <-- closed but needs to be reopened https://github.com/qbittorrent/qBittorrent/issues/7235#issuecomment-357732927

[yegors]

Bump. This needs to be resolved.

[arvidn]

In my testing, it seems that this doesn't happen when terminating any connection, but only when closing the asio interrupt socket, which is a TCP connection over loopback whose purpose it is to wake up the thread blocked in the iocp call, to add another event to wait on to it.

If this can be corroborated, I think the title should be updated.

Furthermore, closing that specific connection causes asio to continuously wake up the iocp thread, that's where the 100% CPU comes from. This is happening because asio doesn't appear to be expecting errors on this socket, but treats all wake-ups as signaled by other parts of the program.

Since this seems to happen when the computer goes to sleep, it seems like a legitimate bug in asio.

[arvidn]

@sledgehammer999 It has been suggested that in your binary distribution of windows build, you patch boost.asio like this: https://github.com/chriskohlhoff/asio/issues/461

[xavier2k6]

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

TEST BUILD

[FranciscoPombal]

@xavier2k6

What exactly do you mean by "fixed"? Are you inferring based on a changelog entry, or have you actually been able to reproduce the problem before and confirmed that the fix is tied specifically to using boost 1.73 vs. any other (recent) version?

For reference, the boost.asio changelog:

https://think-async.com/Asio/asio-1.16.1/doc/asio/history.html#asio.history.asio_1_16_1 (also listed here: https://www.boost.org/users/history/version_1_73_0.html)

[xavier2k6]

I'm basing it off of https://github.com/chriskohlhoff/asio/issues/461#issuecomment-621187438 & the fact that asio 1.16.1 is only included in Boost 1.73 & not any earlier version.

For arguments sake - I can change my comment to "should be/supposed to be fixed"

[FranciscoPombal]

@senposage @yegors mind testing the build linked in https://github.com/qbittorrent/qBittorrent/issues/8740#issuecomment-658109836?

[xavier2k6]

@senposage can you confirm that this issue is fixed or not.

[Seeker2]

I checked again and problem was present in qBitTorrent v4.2.5 with Windows 7 Pro.

Bug seems to be resolved on qBitTorrent v4.3.0 (32 bit version) -- no longer seeing 1 CPU core/thread jump to 100% utilization when qBitTorrent's 2 initial established connections on 127.0.0.1 ip address are broken. As expected, this post is simple confirmation.

[ghost]

This should be closed as this has been confirmed by me to have been fixed by boost 1.73 on another thread long ago.