qBT 3.0.10 >500MB cache size can trigger crash + hashfails

[Dayman]

I wonder why our stacktrace module wasn't triggered. Well, it really looks like we're hitting some kind of limit.

[sledgehammer_999]

[quote="Dayman"]
I wonder why our stacktrace module wasn't triggered. Well, it really looks like we're hitting some kind of limit.
[/quote]

Probably the crash is so serious that the OS doesn't give control back to the app and just wants it to stop executing.

Do you know an easy equivalent on Windows of the Linux debugging way?:

Code: Select all

gdb qbittorrent
**crash**
bt

[Dayman]

Not sure. Windbg is able to attach to processes, but using cdb is pain in the ass.

[Onemoar]

the fix for this is simple don't allow caches bigger then 100MB
seriously there is no need for it beyond 100Mb all you are doing is wasting ram for no reason


the crash is probably something with window X PEE 's file system driver its terrible at handling cached operations
at any rate I tried to reproduce it on 3 different machines  failed
./writes it off as op with terrible computer

[sledgehammer_999]

the fix for this is simple don't allow caches bigger then 100MB

This isn't a proper fix. This is a hack that overlooks the real problem.

@everyone else
I didn't forget this. I'll reply tomorrow with possible steps to debug.

[sledgehammer_999]

1. Install the qbt version that crashes around 500MB ram
2. Download and install WinDbg (debugging tools for windows). Unfortunately there isn't an easy way to get this directly from microsoft(msdn is counterintuitive). I hope this link works: http://www.windbg.org/X86%20Debuggers%2 ... _en-us.msi
3. Launch qbittorrent
4. Launch WinDbg
5. In WinDbg File->Attach to process and select the qbittorrent.exe process
6. In WinDbg Debug->Go
7. Wait for the crash. Visually you won't get something when the crash happens. qBittorrent will freeze and stop responding because the debugger has taken control. In WinDbg in "commands" subwindow will show some entries when the crash happens. In that subwindow type this command !analyze -v
8. Copy/paste the subwindow output here. Hopefully we will get an idea of what is really happening.

[Switeck]

[quote="Onemoar"]at any rate I tried to reproduce it on 3 different machines  failed [/quote]Failed how?

Did you get qBT to use more than 500 or 1600 MB of ram?
Was there no problems even when qBT was using >1700 MB of ram?
Which version/s of qBT were you testing? (32bit/64bit, build date, filename, etc)[quote="sledgehammer_999"]2. Download and install WinDbg (debugging tools for windows). Unfortunately there isn't an easy way to get this directly from microsoft(msdn is counterintuitive). I hope this link works: http://www.windbg.org/X86%20Debuggers%2 ... _en-us.msi[/quote]I couldn't get that to install...it seems to be for a different version of windows.

[Switeck]

For this test, I used:
qbittorrent_3.1.0alpha_22072013_setup.exe

1st crash-run results for qBT in WinDbg:
http://pastebin.com/tr1vrn7q
This showed I hadn't set a symbol path more than anything else and may be just another red herring.

2nd crash-run results for qBT in WinDbg:
http://pastebin.com/g7sg38Xk

Apparently, even when qBT only had a "An I/O error occured, ... Not enough space" error rather than a complete show-stopping crash, I sometimes but not always got hashfails on the downloading BT client.
Because of this, I am worried that any abnormal break/stop/disconnect of the seeding by qBT may trigger hashfails for the other end.

[sledgehammer_999]

I didn't forget you guys. I have a lot going on in Real Life.

Next step is to provide a build with zero compiler optimizations so we can pinpoint exactly the function where it crashes (compilers when optimizing might merge 2 functions together or eliminate others etc)

[sledgehammer_999]

Today my Windows XP BSOD'd 3 times and after that the PC restarts during windows boot. Luckily, I am able to boot into Linux and still access my Windows disk (and files). Probably a hardware failure, maybe motherboard, but until I fix it, I can't do builds and/or development.

[sledgehammer_999]

Here is a new build of git master with optimizations disabled for qbt and libtorrent. It uses libtorrent rev8869 (latest RC_0_16).

1. http://builds.shiki.hu/temp/qbittorrent ... _setup.exe
2. Working link for WinDbg that works on Windows XP sp2: http://www.codemachine.com/downloads/db ... .2.633.msi
3. Install qbt and launch it
4. Launch Windbg
5. In WinDbg File->Attach to process and select the qbittorrent.exe process
6. In WinDbg Debug->Go
7. Wait for the crash. Visually you won't get something when the crash happens. qBittorrent will freeze and stop responding because the debugger has taken control. In WinDbg in "commands" subwindow will show some entries when the crash happens. In that subwindow type this command !analyze -v (notice the exclamation mark)
8. Copy/paste the subwindow output here. Hopefully we will get an idea of what is really happening.

[Switeck]

Crash as usual, at the same memory level (~530 MB).

The debug log was somewhat long, so rather than flooding here I'm linking to it at pastebin:
http://pastebin.com/C2mWkg5R

[sledgehammer_999]

Hmm, the crash report seems the same as the previous ones and doesn't show any libtorrent related function which is weird....
Tomorrow, I'll try to open an issue on libtorrent and try to consult it's author. Maybe he has an idea on how to debug this.

Btw, is there an easy way to make qbittorrent increase memory usage? Ok, I'll change the cache to 1GB but what should I make qbt do in order to reach >500MB cache?

[Switeck]

Some details in how I triggered the bug:
http://qbforums.shiki.hu/index.php/topi ... ml#msg7319

Also, just before the ~530 MB threshold is reached, I attempt to open qBT's Options window with ALT+O. Without doing that final step, the odds of a complete qBT bomb-to-desktop crash is far lower. Timing is critical, I have to have Windows Task Manager open to the side to monitor qBT's memory use to trigger the crash reliably...plus I have to slow down qBT's upload from >10 MB/sec to about 1 MB/sec so it doesn't overshoot the ram trigger point before I can click. If I just let qBT run at 1 MB/sec the whole way, each test would take probably >10 minutes instead of <5 minutes.

You'll need the Disk Cache size set to >500 MB...preferably 1000-2000 MB.
Also, just to give you more time to trigger the bug, set Disk Cache Expiry Interval to 600 seconds (max allowed). Incidentally, 10 minutes seems really short for slowly downloading or uploading 4 MB pieces.

I was previously running torrents small enough to fit entirely within ram cache, so I figured I might as well take advantage of that when I triggered this bug in the first place. But for duplicating the bug, it's best to use 1 torrent of 2-5 GB size.

[sledgehammer_999]

Also, just before the ~530 MB threshold is reached, I attempt to open qBT's Options window with ALT+O. Without doing that final step, the odds of a complete qBT bomb-to-desktop crash is far lower.

So if you don't try to open Options it might not crash. This explains the stacktrace a bit.

plus I have to slow down qBT's upload from >10 MB/sec to about 1 MB/sec so it doesn't overshoot the ram trigger point before I can click.

So, the app can really go to >500MB usage eg 800MB and not crash in that point? The crash is only triggered at around 530MB? And possibly only if you try to open Options?