Open dquixada opened 2 years ago
The workaround is to install any version of libtorrent-rasterbar below 2.x. Currently I have version 1.2.17 installed and the qbit client is stable.
You can use qBittorrent only with the version of libtorrent from which it was built (at least with one of the versions from the corresponding branch, although stability in this case is also not guaranteed).
Yes, I need to rebuild qbittorrent if I want to use another version below 2.x. That's how Gentoo works-- it builds everything from source when it installs packages.
Here's another backtrace from gdb that may have more information in it:
Here's another backtrace from gdb that may have more information in it:
To be honest, I can't imagine how to extract something useful from this whole lot of data... But why is there no stack trace generated by qBittorrent itself? Do you compile it with the STACKTRACE option enabled? Or is it not available when you configure Gentoo package?
I could be wrong but I think backtrace and stacktrace are the same thing. Otherwise, there are no other build flags that look like "stacktrace":
https://packages.gentoo.org/packages/net-p2p/qbittorrent
Anyway, here's another backtrace with more information:
Hopefully that has what you need.
I could be wrong but I think backtrace and stacktrace are the same thing.
qBittorrent's produced stack trace looks like in https://github.com/qbittorrent/qBittorrent/issues/17492.
@dquixada Was qBittorrent installed before and working fine or do you try to run it on your machine for the first time?
I'll see if I can generate the stacktrace to look like the one you provided. I may need help from the devs at Gentoo though.
qbittorrent was working fine until it was updated with a libtorrent-rasterbar library >2.x. It took me awhile to figure-out that this was the problem though. The stable Gentoo repos are a little behind when it comes to newer versions of packages. Currently, 4.4.3.1 is the "unstable" version available. However, I have the same trouble with the "stable" earlier versions.
qbittorrent was working fine until it was updated with a libtorrent-rasterbar library >2.x. It took me awhile to figure-out that this was the problem though.
Could you try to run qBittorrent with clean profile? Either by moving your existing data to some other place or by using --profile=path-to-some-empty-dir
command line parameter?
Ok so I did what you suggested. I started a new profile with a blank dir and qbittorrent has been running empty for about 12 hours now. It would normally have crashed by now.
I also tried to load the previous settings using the --configuration flag but I don't think it worked because when I use the flag it doesn't seem to load the settings when I check them within the program.
Anyway, I think this narrows things down a little bit. Any other suggestions on next steps?
Anyway, I think this narrows things down a little bit. Any other suggestions on next steps?
Now it seems that the problem is caused either by some kind of setting, or (more likely) by some kind of torrent. To determine if it is the first or the second, you could copy the contents of your original BT_backup
folder to the new profile (unless you use SQLite based storage). If the crash happens again, you can try to identify a specific torrent by sequentially deleting .fastresume
files from the BT_backup
folder.
I can try that, but narrowing down which torrent it is would take a very long time! Why would this be happening only with libtorrent-rasterbar-2+ libraries and to earlier ones? Was there a fundamental change made between the two major-versions? If we know what that is, it may help narrow down which torrent(s) is(are) causing the problem...
Ok, I copied the BT_backup folder in and it crashed after a few minutes. It also outputted this stacktrace:
Caught signal: SIGSEGV Stack trace: /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x1226f0 [0x7f73b30f66f0] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x14c728 [0x7f73b3120728] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x14d490 [0x7f73b3121490] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0xe4847 [0x7f73b30b8847] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24eab1 [0x7f73b3222ab1] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24ed21 [0x7f73b3222d21] /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6 : ()+0xd45b0 [0x7f73b17b05b0] /lib64/libc.so.6 : ()+0x863ea [0x7f73b146a3ea] /lib64/libc.so.6 : ()+0x1082dc [0x7f73b14ec2dc] Segmentation fault
It also outputted this stacktrace:
Well, that's not much better... qBittorrent stacktrace feature still doesn't work correctly. It looks like the debug info is unavailable. Maybe package maintainer deliberately changed the build parameters to reduce the size of the binary.
Why would this be happening only with libtorrent-rasterbar-2+ libraries and to earlier ones? Was there a fundamental change made between the two major-versions?
The major change is adding support for BitTorrent v2 so there could be a reason in it. But you couldn't add pure v2 torrents earlier (when you used libtorrent-1.2). You could only add a hybrid torrent, so you can try looking for one (i.e. one that has both v1 and v2 info hashes).
That may actually help narrow things down quite a bit as I think most of my torrents are v1. Is there a way to filter v1, v2 or hybrid torrents in qBittorrent? If not, what other way can I use to determine what type of torrent it is?
Unfortunately, only click on each one and see what is displayed in Properties view.
But if you are competent enough to search for the occurrence of a regular expression in the contents of .fastresume
files, then info-hash232:\w
should help you.
Ok grepping the .fastresume files as well as clicking through them (for good measure) revealed no v2 torrents.
I should also point out that when I run the GUI from the command line I get this warning:
libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile
Not sure if it's critical though...
Regarding the backtrace: try FEATURES="-nostrip -splitdebug -compressdebug" CFLAGS="-O2 -ggdb3" CXXFLAGS="-O2 -ggdb3" emerge -v1 qbittorrent libtorrent-rasterbar.
It'll avoid splitting the debugging symbols.
Ok grepping the .fastresume files as well as clicking through them (for good measure) revealed no v2 torrents.
Well, let's continue triaging (if you're not tired of it yet).
Do you have unfinished torrents in your list? Do you have torrents added via magnet link that still have no metadata received?
I have three that are stalled downloading at 0% (and have been for awhile-- especially one). I have 9 paused torrents because they got moved and then modified and I didn't want to re-download them. I have one errored with missing files (not sure what happened there) and apparently two are "checking" but when I click on that status, none actually show up there.
I may have added a few magnet links but I'm not sure which ones, is there a way to tell? I can delete all those ones though as I wouldn't care about those.
@thesamesam, thanks, I will report back once I've re-built the packages.
I may have added a few magnet links but I'm not sure which ones, is there a way to tell?
There are no files in Content view. And maybe no size in torrent list.
Anyway we're interested in non-paused torrents since the paused ones are unlikely to be the cause of the crash.
@glassez, I don't appear to have any magnets.
@thesamesam, I rebuilt with the flags you suggested and here's the resulting backtrace:
Is the latest backtrace enlightening at all?
Sorry, my suggestion was to make qbittorrent give its own useful backtrace when you ask it to (see above where you gave one that didn't have much info). It won't make gdb any more useful as gdb already knows how to look for split symbols.
Here is the stacktrace after qbittorrent and rasterbar were built with your suggested parameters:
$ qbittorrent
Please file a bug report at http://bug.qbittorrent.org and provide the following information:
qBittorrent version: v4.4.3.1
Caught signal: SIGSEGV Stack trace: /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x1226f0 [0x7fc7ef96f6f0] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x14c728 [0x7fc7ef999728] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x14d490 [0x7fc7ef99a490] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0xe4847 [0x7fc7ef931847] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24eab1 [0x7fc7efa9bab1] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24ed21 [0x7fc7efa9bd21] /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6 : ()+0xd45b0 [0x7fc7ee0295b0] /lib64/libc.so.6 : ()+0x863ea [0x7fc7edce33ea] /lib64/libc.so.6 : ()+0x1082dc [0x7fc7edd652dc] Segmentation fault
There doesn't seem to be much more; however, I did notice that I was getting lots of tracker errors. Mainly "unable to connect" or "SOCKS authentication error". The number in the 'Error' category in the 'Transfers' window kept increasing into the 100s and then qbittorrent would crash.
My workaround (if you want to call it that) was to pause all the torrents and qbit no longer crashed. I have been slowly reactivating the torrents and have noticed that if I activate too many at once the program crashes; but if I activate a few at a time it doesn't crash. It also doesn't seem to depend on any particular torrent-- the crash happens with torrents that were previously activated in small batches but when they are activated in a larger batch the crash will happen. I still even get errors if I reactivate in five or six at a time but if I "force re-announce" then I eventually get the error to go away and it connects to the tracker.
Maybe this narrows down things a bit? Although, I'm not sure why it wouldn't crash when using less than v2 of libtorrent-rasterbar though.
I will also add that my "workaround" is not very practical as it means that I'd need to slowly re-activate the torrents in small batches every time I start-up qbittorrent.
Here is the stacktrace after qbittorrent and rasterbar were built with your suggested parameters
It's still not what it should be.
In fact, qBittorrent is distributed with configuration files for CMake and Automake build systems that have the correct flags for STACKTRACE feature.
I'll let the Gentoo folks know.
Is my observation about the tracker errors of any use? or is it a red herring?
BTW, I quit during a lot of the errors and got a different stacktrace:
free(): corrupted unsorted chunks
Please file a bug report at http://bug.qbittorrent.org and provide the following information:
qBittorrent version: v4.4.3.1
Caught signal: SIGABRT Stack trace: /lib64/libc.so.6 : ()+0x880a4 [0x7f5872ffd0a4] /lib64/libc.so.6 : raise()+0x12 [0x7f5872fb24a2] /lib64/libc.so.6 : abort()+0xcf [0x7f5872f9d469] /lib64/libc.so.6 : ()+0x7c848 [0x7f5872ff1848] /lib64/libc.so.6 : ()+0x91a7a [0x7f5873006a7a] /lib64/libc.so.6 : ()+0x93a5f [0x7f5873008a5f] /lib64/libc.so.6 : free()+0x62 [0x7f587300b082] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x1e02eb [0x7f5874d452eb] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0xe4847 [0x7f5874c49847] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24eab1 [0x7f5874db3ab1] /usr/lib64/libtorrent-rasterbar.so.2.0 : ()+0x24ed21 [0x7f5874db3d21] /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libstdc++.so.6 : ()+0xd45b0 [0x7f58733415b0] /lib64/libc.so.6 : ()+0x863ea [0x7f5872ffb3ea] /lib64/libc.so.6 : ()+0x1082dc [0x7f587307d2dc] Aborted
@dquixada is this still relevant ?
qBittorrent & operating system versions
qBittorrent: 4.4.3.1 Operating system: Gentoo Linux (5.15.52 kernel) Qt: 5.15.5 libtorrent-rasterbar: 2.x (tested: 2.0.5, 2.0.6, 2.0.7)
What is the problem?
I reported this on the Gentoo bugtracker and, after some investigation, I was asked to report here. The bug is located here for reference: https://bugs.gentoo.org/839567
Steps to reproduce
Additional context
Here is a copy of the backtrace from gdb:
https://pastebin.com/AJWFAJJt
This particular attempt was using rasterbar 2.0.7
The workaround is to install any version of libtorrent-rasterbar below 2.x. Currently I have version 1.2.17 installed and the qbit client is stable.
Log(s) & preferences file(s)
Click
[AboutDialog] Size=@Size(545 330) [AddNewTorrentDialog] DialogSize=@Size(900 759) Enabled=true Expanded=true RememberLastSavePath=false SavePathHistory=