mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
[Crash] [WinDbg Report] qBT is crashing every 48h (or less) on Win7 x64. #1 #4307
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#4307
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 @Misiek304 on GitHub (May 24, 2016).
Hi,
My qBittorrent instance is crashing since I can remember. Probably after I started using 3.3.x branch. It's happening every 48h or less. I'm on Windows 7 x64 updated up to January 2016. I wrote about this issue before but no one was able to help. #5050
Yesterday I used this instruction from @sledgehammer999
And this is the output from the most recent crash:
Here is also a pastebin link: http://pastebin.com/mf6x23uF
@adamralph commented on GitHub (May 24, 2016):
It's also crashing for me with about the same frequency.
qBittorrent 3.3.4
Windows 10 Pro x64, Version 1511, OS Build 10586.318
@Misiek304 commented on GitHub (May 25, 2016):
And there's another one.
http://pastebin.com/y75tutQ2
@zeule commented on GitHub (May 25, 2016):
@Misiek304: Your first log shows that it crashed with
std::bad_allocexception (which is thrown when memory allocation fails). Can you, please, watch the qBt memory usage, especially when it is close to the expected crash time? Your second crash log is unrelated to that problem.@Misiek304 commented on GitHub (May 25, 2016):
How would you like me to monitor memory usage? It would be best if there was some log function.
Also, should I open another issue with the second debug report?
@zeule commented on GitHub (May 25, 2016):
Does qBt show a steady increase of the memory footprint or does it try to allocate a lot just before a crash?
@zeule commented on GitHub (May 25, 2016):
This is certainly a different problem, so, I think, opening another issue would be correct.
@Misiek304 commented on GitHub (May 25, 2016):
I haven't noticed anything like that.
@zeule commented on GitHub (May 25, 2016):
Then we suppose that its attempt to allocate a string of size 3131961358 bytes (in a block of 3131961393 bytes) is the first one.
@Misiek304, sorry, I did not find qbt version number in your report. We need to know it to understand what was in line 2496 of g:\qbittorrent\libtorrent\src\torrent.cpp for that build.
@sledgehammer999 commented on GitHub (May 25, 2016):
I think this is a case where the memory footprint(of qbittorrent) keeps growing until it reaches close to 2GB. And then it crashes because that's the limit for 32bit applications on Windows.
For v3.3.4 I used libtorrent 1.0.8+git602dc02. But I don't think this matters if we wait for the next crash (every 48h) it will still happen when trying to allocate memory and at a different place.
I am sure there are online plenty memory monitoring/logging tools(per process) for windows that you could use.
@zeule commented on GitHub (May 25, 2016):
@sledgehammer999, look, it tries to allocate a huge string (if the stack trace is correct) with size of 2.9 GB. Is it consistent with your point of view?
@sledgehammer999 commented on GitHub (May 25, 2016):
Hmm, I missed that. I didn't read the values. Then you may be indeed right. That string is too big.
Should we tag arvidn?
@zeule commented on GitHub (May 25, 2016):
The line 2496 of libtorrent\src\torrent.cpp in git602dc02 does not correspond to the stack trace. Maybe it is not 3.3.4?
@Misiek304 commented on GitHub (May 25, 2016):
That's the version I'm currently using. And one more thing. I don't have a g:\ drive so there is no g:\qbittorrent\libtorrent\src\torrent.cpp on my computer. Hope that helps.
@zeule commented on GitHub (May 25, 2016):
Thank you.
Paths in a stack trace are from the build machine.
@sledgehammer999, line 2496 is
I can not understand that.
@sledgehammer999 commented on GitHub (May 25, 2016):
I cannot test the type at the moment but I suspect that "bind_ip" is an std::string which corresponds to the stacktrace.
@zeule commented on GitHub (May 25, 2016):
No, it is
boost::asio::ip::address. But the previous line is:and
urlisstd::string, of course.@sledgehammer999 commented on GitHub (May 25, 2016):
Let's say this is the right line. @Misiek304 can you check the trackers of all your torrents and see if the url to one of them is very very big?
@Misiek304 commented on GitHub (May 25, 2016):
I have more than 300+ torrents. Any idea how to list all trackers URLs? I'm looking though for the long once's on the left (trackers column) and don't see anything extremely long but I found something like that:
http://197.239.0.98:8085/announce?from=CSS
http://bt4.rutracker.cc/ann?magnet
http://bt.rutracker.cc/ann
http://bt-club.ws/announce.php
*udp://open.demonii.com:1337
Those were probably the longest once's I could find:
udp://tracker.windsormetalbattery.com:80/announce
http://tracker.tvunderground.org.ru:3218/announce
http://tracker.windsormetalbattery.com:80/announce
http://academic-p2p.carlosdelfino.eti.br/announce
@sledgehammer999 commented on GitHub (May 25, 2016):
I think it is better to wait for your next crash and compare that backtrace too.
If you're already running qbittorrent then choose from WinDbg file->attach to a process... instead of open executable.
Then wait for it to crash.
@Misiek304 commented on GitHub (Jun 1, 2016):
So I finally had another one. Sorry it took so long but for some reason it worked straight for a few days without a crash.
Here's the link:
http://pastebin.com/RxMRfmYp
@adamralph commented on GitHub (Jun 1, 2016):
I had the same thing. About a week with no crashes and then yesterday it started again. 4 or 5 crashes.
@zeule commented on GitHub (Jun 1, 2016):
thank you, this one is similar: again
std::bad_allocand the new string size this time is 1827801399 bytes (1.7 GiB), and it happened again atSince it happens randomly, could it be that a tracker sends a garbage and libtorrent reacts by allocating a huge string?
@arvidn, could you tells us your opinion on this, please?
@zeule commented on GitHub (Jun 1, 2016):
@adamralph, do you mean the similar back-trace? It would be interesting to check, in that case, whether you and @Misiek304 can had the same active torrents at the time of crash....
@adamralph commented on GitHub (Jun 1, 2016):
@evsh no, just the end symptom. I haven't done any technical investigation at all I'm afraid.
When I get a chance, I'll get the app running under Windbg instead.
@zeule commented on GitHub (Jun 1, 2016):
@adamralph but qBt should show backtrace in its crash report. That would be helpful too.
@Misiek304 commented on GitHub (Jun 1, 2016):
@evsh I would be careful with those crash reports from qBittorrent. I got none, really not even one. The app just hangs. I saw crash report window once though. It was blank so...
And also up to recently I have had "exchange trackers with other peers" enabled. So there is a possibility that some peer gave me a bad tracker.
Also just a thought. Can this be somehow connected to downloading tracker favicon? I can see some errors in qBT logs about the app not being able to download one for some trackers.
@arvidn commented on GitHub (Jun 2, 2016):
could somebody give this a try?
github.com/arvidn/libtorrent@aae42bc8be@Misiek304 commented on GitHub (Jun 2, 2016):
Since I reported this issue I'm willing to try the fix if someone would provide me with an .exe file for Win7 x64.
@sledgehammer999 commented on GitHub (Jun 2, 2016):
@Misiek304 use this build: http://builds.shiki.hu/temp/qbittorrent_3.3.4_with_libtorrent_aae42bc_for_issue_5294.7z
@Misiek304 commented on GitHub (Jun 6, 2016):
I've been using this fix for a few days now and I haven't encounter this type of crash since. I think that this patch is working well. Are the alpha builds from http://www.fosshub.com/qBittorrent.html have this fix included?
@adamralph Can you confirm? Are you using this fix yourself?
@sledgehammer999 commented on GitHub (Jun 6, 2016):
Not yet. (Look at the timestamp).
The libtorrent fix will be included in v3.3.5 and newer alpha builds.
Thanks for reporting back. Closing.
@adamralph commented on GitHub (Jul 2, 2016):
I've upgraded to 3.3.5 and all looks good so far. Thanks!
@adamralph commented on GitHub (Jul 2, 2016):
Should this issue be assigned to the 3.3.5 milestone?
@Misiek304 commented on GitHub (Jul 2, 2016):
It's fixed. Let's leave it at that. 😃
@adamralph commented on GitHub (Jul 11, 2016):
I'm still getting crashes in 3.3.5
@Misiek304 commented on GitHub (Jul 11, 2016):
Then I think you should create another issue thread and include your WinDbg raport from the crash. Your problem might have the same symptoms but it can also be unrelated to my issue.