mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
the program remains running after explicit EXIT #562
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#562
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 @shula on GitHub (May 25, 2013).
After I click "EXIT" on the taskbar,
or when I press Alt-F4
or click the close button ("X"),
this is my setup
qBittorrent-3.1.0alpha-release-3.0.0-355-g07ec2cc-x64-setup.exe
win7 x64
but i've seen something similar on the 3.0.9 official release.
More details:
When closing the program, the main window closes, the taskbar & tray icon disappear,
but the application remains in the process list.
Edit:
After following it a bit, the I/O doesn't change, but CPU is 1%-5%. So it's doing something in the bg.
("funny" thing is, it remains resident, even if i try to kill it (taskkill /F, tasklist, processExplorer, etc). it wouldn't close, not even show the "closing..." dialog.)
When I run the program again (after it have been closed), it start an additional process,
starts the splash-screen, and the new process' I/O is running up as it should.
But then also the "zombie" process goes back to life, its CPU is rising, and have a little bit of I/O activity.
I'd prefer that when i close a program, it will be really closed, not "ghost".
@ximply commented on GitHub (May 25, 2013):
It just saves fastresume data when quit so that it will spend some time doing this work.
@thores commented on GitHub (May 25, 2013):
This happens to me too. I use v3.0.9 and Windows XP.
qBittorent resides in memory after closing. I can't even kill the process with ctrl+alt+del.
To make it worse, I can't even restart qBittorent after trying to close it. To restart it requires to re-boot XP.
@thores commented on GitHub (May 25, 2013):
What's more, execution log says "fast resume rejected; mismatching file timestamp" and "fast resume rejected; missing or invalid file sizes entry". This happens every time I start qBittorent.
@shula commented on GitHub (May 25, 2013):
@ximply - it never terminates. Just stays there forever. can't switch to it, can't kill it.
@thores - how do i see the log?
@sledgehammer999 commented on GitHub (May 25, 2013):
@thores This is already fixed with a special build: http://qbforums.shiki.hu/index.php?topic=1865.0
@shula Please try the above build and report back.
@ximply commented on GitHub (May 26, 2013):
I cannot open [http://qbforums.shiki.hu/index.php?topic=1865.0] this page, just show this page cannot display.
@thores commented on GitHub (May 26, 2013):
@shula Make sure View -> Execution Log is checked. Then the Execution Log Tab next to the Transfers tab becomes visible.
Will try the special build.
@bdcarr commented on GitHub (May 27, 2013):
I'm having a similar problem with the 3.0.9 official release on Win7 x64. It doesn't happen all the time, but when I explicitly close the application the process keeps running, using the same amount of RAM it was before, ever so slightly creeping up until it reaches about 75MB. CPU usage reads less than 0.01%.
But I can kill the process just fine. Until I kill it, however, I'm unable to open another instance of it. Attempting to open another instance creates a new process with minimal (~2-3MB) RAM usage and no apparent CPU usage. I can repeat this as many times as I like, but after about thirty seconds of half-life, the processes are auto-killed.
Hope this data helps.
Oh, and I'll try that build once qbforums comes back online and report back.
@ximply commented on GitHub (May 27, 2013):
I try this too, but I still find it stay alive to save something to disk, then about one minute later it exit.
My OS: Win8 x64.
@sledgehammer999 commented on GitHub (May 27, 2013):
The admin of the forums is currently in the process of changing hosts. Expect some downtime and probably tomorrow all will be fine and hopefully stable.
I don't know if you are now able to access the forums but I'll copy the download links here for easier access:
Normal 3.0.9 source, with the libtorrent fix included(which now is included in libtorrent 0.16.10)
@ximply I think that's normal for 700 torrents. If you want to take a closer look at the code take a peek at QBtSession::saveFastResumeData() which is called only at program exit. I don't think there is anything you can apart from waiting for the alerts to be posted on the queue... It all depends on libtorrent in that point.
@bdcarr commented on GitHub (May 27, 2013):
Just installed that special build, thanks.
It doesn't seem to have helped. I just ran the program, let four torrents become active and download for about a minute, then exited the application. Four minutes later, the process is still there. RAM usage doesn't seem to have increased.
My computer's powerful enough that any disk-writing that a program like qBittorrent is performing should be done by now. Just had an idea...
Okay, so I've restarted qBittorrent and let it download for a few seconds. One of the transfers has reached 455.5MB downloaded, at a rate of about 60kb/s. I suspect my ISP is throttling bittorrent transfers, but anyway...
Exited application, process remained, waited a minute, killed process and re-opened application. Whatever it's doing, it's not downloading, because the transfer remained at 455.5MB.
This time when I exited, the process remained for a minute before finishing seemingly on its own.
@sledgehammer999 commented on GitHub (May 27, 2013):
@flyingsandwich Just a quick thought: Try rebooting your modem/router. This special build was for problem that occurred mostly on Windows XP machines. For qBittorrent to not close it means that it waits for something. In the WinXP problem the disk-io thread of libtorrent got stuck you couldn't shutdown libtorrent. Now, maybe the problem lies somewhere in the network-thread of libtorrent getting stuck...
@bdcarr commented on GitHub (May 28, 2013):
I'll try that, later, when it won't be disrupting the rest of the household.
In the meantime, is there a way to write the execution log to a file as
it's being written? If it's able to write to the log while the process is
hanging on for dear life, maybe there'll be a clue in there. Of course, I
can't view it the normal way because the window's already closed.
On Tue, May 28, 2013 at 8:27 AM, sledgehammer999
notifications@github.comwrote:
@Gelmir commented on GitHub (May 28, 2013):
Happened to be too. Couldn't kill the process. Was reproducible only with a particular torrent.
@sledgehammer999 commented on GitHub (May 28, 2013):
@Gelmir Will you be able to work on this?
@Gelmir commented on GitHub (May 28, 2013):
Not sure. Even if I find time, I'll have to reDL the torrent and make sure I can reproduce the issue. Moreover I don't know how to start debugging a deadlock (and that's what this probably is).
@sledgehammer999 commented on GitHub (May 28, 2013):
Can you give me a link to the torrent to test if it deadlocks for me too? (or pm if you want)
@spryte123 commented on GitHub (May 29, 2013):
My experience has been practically the same as the 1st post. And the only way to get my pc back was with a hard-reset.
Furthermore
What might be helpful to you.
I've solved my problem by re-installing version 3.0.6 on winXP
To re-iterate, I only changed the version. Everything else stayed the same. Notably nothing on my network or my Router without a forwarded port (which has never been required by me) was changed. Although I had tried disabling all my Antivirus, firewalls, ip filters and other background programs previously, all were back "on" for my last attempt on 3.0.9 and then when I started up 3.0.6
Hopefully this will help you guys find the problem.
@sledgehammer999 commented on GitHub (May 29, 2013):
@spryte123 It could be really helpful if you tried this special build and report back if it worked: http://qbforums.shiki.hu/index.php?topic=1865.0
Thank you.
@Gelmir commented on GitHub (May 30, 2013):
Can't reproduce anymore. I've probably encountered the bug with 16.9, and currently I have 16.10.
Will need to update my installer this week, waiting for resolution on #224
@spryte123 commented on GitHub (May 30, 2013):
As requested ... I tried the "special build" out on my 2nd XP machine. (I wasn't going to fiddle with the other one as I need it to be working and I don't have time to fix it if anything else went wrong.)
Started with the 3.0.8 version installed on PC2. Working but seemed sluggish.
Installed 3.0.6
Installed 3.0.9
Installed Special Build 3.0.9
Interestingly the same torrents dowloaded even faster, after I delete them + the partial files, and re-added them. (I was concerned the files might be corrupted after all my fiddling with them and only had about 10% downloaded anyway. So I started fresh. I'd guess this was cos some peers got "lost" or "ignored")
So I would seem the special build does fix the problem, in my case at least.
@UrbanPotato commented on GitHub (Jun 4, 2013):
this is still a issue
I recommended that QbT have a Force-terminate for "only allow one instance" a few reports ago as there is really no way of fixing it because its a Quirk with the way Windows handles processes that still have open "handles" to the file-system and I am pretty sure rewriting qBT so it force-ably unloads all the handles without causing check-sum errors would require a substational rewrite the best thing they can do is do a 'softquit' and then check back in ~30 seconds if it still doesn't shutdown have it forcibly terminate its self(messy)
@sledgehammer999 commented on GitHub (Jun 4, 2013):
@rjc862003 Do you experience this problem? If yes, did you try the special build linked above? Also please post your system info.
It would be great if others tried the build mentioned above and posted back here. Otherwise we cannot further debug this.
@UrbanPotato commented on GitHub (Jun 4, 2013):
all the builds that have been posted have the problem its not a problem with qBT its a problem with windows and torrent clients in general
uTorrent does the same thing
so does VUZE
ect ect
@sledgehammer999 commented on GitHub (Jun 4, 2013):
Did you try the special build? Does it still hang forever on exit, without any CPU usage? If yes, please post your system info and how many torrents you usually have.
Unless you refer to a slightly different issue: That the process stays alive for several seconds with relatively high CPU usage before finally exiting. This is totally normal, when many torrents are involved(more than 100).
@shula commented on GitHub (Jun 4, 2013):
body p { margin-bottom: 0.6cm; margin-top: 0pt; }
i was refering to the "no-CPU, remain
forever" issue, not the other one (which looks like a normal
behabior).
As someone else noted before, it happens only sometimes.
Sorry, I didn't have the chance to check if it relates to a
certain type of torrent files, or to test the provided build .
On 05/06/2013 00:11, sledgehammer999 wrote:
@v6bit commented on GitHub (Dec 13, 2013):
I meet the problem using qbittorrent v3.1.3 in win8
Actually, this problem always exits ,maybe cause by libtorrent
@sledgehammer999 commented on GitHub (Jan 28, 2014):
Can you try the fix mentioned in this comment? https://github.com/qbittorrent/qBittorrent/issues/1332#issuecomment-33401723
@sledgehammer999 commented on GitHub (Feb 8, 2014):
@ everyone
Can you try the fix mentioned in #1332 ?
In a command prompt
@sledgehammer999 commented on GitHub (Feb 8, 2014):
Let's continue discussion at #1332