Created attachment 771971 [details] backtrace.log I'm having major problems here with qbittorrent. It crashes after a few minutes. I've attached the backtrace.log Here's the output from gdb for this backtrace: Thread 5 "qbittorrent" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeaffd640 (LWP 7083)] 0x00007ffff7bb3ff3 in boost::asio::detail::reactive_socket_service_base::close (ec=..., impl=..., this=0x7fffe00b0) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:109 109 reactor_.deregister_descriptor(impl.socket_, impl.reactor_data_, I've also, gotten this error: Thread 5 "qbittorrent" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeaffd640 (LWP 16270)] 0x00007ffff7bb3ff3 in ?? () from /usr/lib64/libtorrent-rasterbar.so.2.0 But after and 'emerge -e qbittorrent' I've been getting the topmost error. Here are the build flags: net-p2p/qbittorrent-4.3.9::gentoo USE="X dbus -debug -webui" And the relevant supporting packages: x11-libs/libICE-1.0.10-r1 x11-libs/libSM-1.2.3-r1 net-libs/libtorrent-rasterbar-2.0.5 dev-qt/qtcore-5.15.3 Note that I brought this issue up on the forums here: https://forums.gentoo.org/viewtopic-p-8700713.html#8700713
I think your attachment is truncated: it doesn't contain "segmentation fault". Please also include emerge --info.
Please change the bug status to UNCONFIRMED once the requested information has been provided.
Created attachment 772187 [details] emerge --info As requested.
Created attachment 772190 [details] full backtrace.log Hopefully this contains what you need.
(In reply to don quixada from comment #4) > Created attachment 772190 [details] > full backtrace.log > > Hopefully this contains what you need. Searching on mobile but I don't see "segmentation fault" in there still?
Hmm, yeah I don't see it in there specifically with 'seg' or 'SEG' either. I'm creating the backtrace in gdb with: thread apply all bt full Am I missing a step? Also note that when it crashes it do get: Thread 5 "qbittorrent" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeaffd640 (LWP 11097)] 0x00007ffff7bb3ff3 in boost::asio::detail::reactive_socket_service_base::close (ec=..., impl=..., this=0x7ff81f801929) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:109 109 reactor_.deregister_descriptor(impl.socket_, impl.reactor_data_, Maybe that helps?
Created attachment 772196 [details] Excerpt from backtrace.log: Thread 5 (0x7fffeaffd640)
I've created an excerpt for that Thread 5 I mentioned in the previous comment and added it as an attachment. Maybe that helps?
Ok so I got tired of qbittorrent crashing all the time and decided to install Deluge. When I did this, it did a rebuild of rasterbar into a different slot. It also rebuilt qbittorrent, so I decided to run qbittorrent instead and now it's been running several days without crashing! So I don't know what the next steps are but it seems that if qbittorrent-4.3.9 is built with libtorrent-rasterbar-1.2.15-r1 instead of libtorrent-rasterbar-1.2.15 stability is restored. Here is the output of emerge -p deluge: https://pastebin.com/b67jGhCM
(In reply to don quixada from comment #9) > Ok so I got tired of qbittorrent crashing all the time and decided to > install Deluge. When I did this, it did a rebuild of rasterbar into a > different slot. > > It also rebuilt qbittorrent, so I decided to run qbittorrent instead and now > it's been running several days without crashing! > > So I don't know what the next steps are but it seems that if > qbittorrent-4.3.9 is built with libtorrent-rasterbar-1.2.15-r1 instead of > libtorrent-rasterbar-1.2.15 stability is restored. > > Here is the output of emerge -p deluge: > > https://pastebin.com/b67jGhCM oh, excellent! I'm guessing it's to do with the complete change in the ebuild (and to CMake). Nice.
(In reply to Sam James from comment #10) > (In reply to don quixada from comment #9) > > Ok so I got tired of qbittorrent crashing all the time and decided to > > install Deluge. When I did this, it did a rebuild of rasterbar into a > > different slot. > > > > It also rebuilt qbittorrent, so I decided to run qbittorrent instead and now > > it's been running several days without crashing! > > > > So I don't know what the next steps are but it seems that if > > qbittorrent-4.3.9 is built with libtorrent-rasterbar-1.2.15-r1 instead of > > libtorrent-rasterbar-1.2.15 stability is restored. > > > > Here is the output of emerge -p deluge: > > > > https://pastebin.com/b67jGhCM > > oh, excellent! I'm guessing it's to do with the complete change in the > ebuild (and to CMake). Nice. Apologies, the version of libtorrent-rasterbar that was previously 2.0.5 not 1.2.15.
I am curious, why did you close the ticket? The workaround seems to be working so far but installing a different program so this will work doesn't seem like a good permanent solution. If someone installs qbittorrent, it would only install the unstable version of libtorrent-rasterbar. Although maybe I'm the only person with this problem? So I get that you would close it but installing a completely different software package to solve a problem doesn't seem like a good solution to me.
It's just because I misread. Anyway, I think at this point, we need to report it upstream. Could you do that?
(In reply to Sam James from comment #13) > It's just because I misread. Anyway, I think at this point, we need to > report it upstream. Could you do that? I can do that... if I knew how. What are the steps?
Hi Sam, any update? I'm just wondering what to do next. Thanks.
Hi Sam, It looks like David Seifert dropped version 1.2.15-r1 of libtorrent-rasterbar about a month ago. After a @world update I lost this version and cannot get it back now because it was dropped. Is there a way for you to re-add it to the repository so I can reinstall the older library? I masked 2.0.6 but there is nothing to fall back on now. Here's the reference to the drop of this version: https://gitweb.gentoo.org/repo/gentoo.git/commit/net-libs/libtorrent-rasterbar?id=0d9916f56c377aab4143f2f2b157f62d97e2da0f Also, would appreciate how to move this bug along so it can get some attention "upstream".
(In reply to don quixada from comment #16) > Hi Sam, > > It looks like David Seifert dropped version 1.2.15-r1 of > libtorrent-rasterbar about a month ago. After a @world update I lost this > version and cannot get it back now because it was dropped. > > Is there a way for you to re-add it to the repository so I can reinstall the > older library? > > I masked 2.0.6 but there is nothing to fall back on now. > > Here's the reference to the drop of this version: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/net-libs/libtorrent- > rasterbar?id=0d9916f56c377aab4143f2f2b157f62d97e2da0f > I guess we can for now. > Also, would appreciate how to move this bug along so it can get some > attention "upstream". You'll need to report it at https://github.com/qbittorrent/qBittorrent and walk through any debugging steps they offer. It's really beyond my abilities to help with at this point, as it's an issue in the code, not our packaging.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6b0d1e9aab2d8d1852a1410c14a9efdc3a9b45d commit d6b0d1e9aab2d8d1852a1410c14a9efdc3a9b45d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-29 04:23:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-29 04:24:03 +0000 net-libs/libtorrent-rasterbar: restore old 1.2.16 for now for crash bug Partly reverts 0d9916f56c377aab4143f2f2b157f62d97e2da0f. Bug: https://bugs.gentoo.org/839567 Signed-off-by: Sam James <sam@gentoo.org> net-libs/libtorrent-rasterbar/Manifest | 1 + .../libtorrent-rasterbar-1.2.16.ebuild | 69 ++++++++++++++++++++++ 2 files changed, 70 insertions(+)
(In reply to Sam James from comment #17) > (In reply to don quixada from comment #16) > > Hi Sam, > > > > It looks like David Seifert dropped version 1.2.15-r1 of > > libtorrent-rasterbar about a month ago. After a @world update I lost this > > version and cannot get it back now because it was dropped. > > > > Is there a way for you to re-add it to the repository so I can reinstall the > > older library? > > > > I masked 2.0.6 but there is nothing to fall back on now. > > > > Here's the reference to the drop of this version: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/net-libs/libtorrent- > > rasterbar?id=0d9916f56c377aab4143f2f2b157f62d97e2da0f > > > > I guess we can for now. > > > Also, would appreciate how to move this bug along so it can get some > > attention "upstream". > > You'll need to report it at https://github.com/qbittorrent/qBittorrent and > walk through any debugging steps they offer. > > It's really beyond my abilities to help with at this point, as it's an issue > in the code, not our packaging. When you report it upstream, please share the link here. It'd really help to have the full backtrace (share full output from starting gdb, running 'bt', end) too.
sorry, one more thing: have you built parts of your system with GCC 10 and some with GCC 11? It may be worth picking one (pick 11 ideally, please!) then running: revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc.
Thank you, I was able to build qbit with the libtorrent-rasterbar-1.2.17 (~amd64) library. I'm now running a stable client (so far at least!). Regarding GCC, I'm using 11 exclusively. I will report it upstream as you instructed (thanks for the explanation).
One question before I submit a bugreport on the qbittorrent issues tracker... I noticed that the latest stable version of qbit is 4.4.3.1 and the one available on Gentoo is 4.3.9 (with no ~ versions available above this version). There is a chance this issue has been fixed in later versions. If I submit a bugreport there, is there a chance that my report on their bug tracker will be ignored because I'm reporting a bug from a previous version? Is there a way to get the code from the latest version of qbit in the Gentoo repository even if it is marked as 'unstable'?
Note: I just checked the repo and it appears that version 4.4.3.1 is now available as 'unstable' is the repo. I am building now (with libtorrent-rasterbar-2.0.6) and will report back any errors.
Update: I built the 4.4.3.1 version of qbit including the latest "stable" version of libtorrent-rasterbar (2.0.6). Then the latest "unstable" version (2.0.7). Qbit still crashed (although it took longer with 2.0.7). I then built it with libtorrent-rasterbar-1.2.17 and qbit has been stable (so far).
Reported: https://github.com/qbittorrent/qBittorrent/issues/17489
(In reply to don quixada from comment #25) > Reported: > > https://github.com/qbittorrent/qBittorrent/issues/17489 Looks like the backtrace is still incomplete. Can you make sure you include output from the beginning of running gdb right to the end? And yeah, always best to try with latest versions, as you did in the end. Also, thanks!
How do I do this? I'm following the instructions from here: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces $ gdb -q /usr/bin/xine (gdb) run [...] (gdb) set logging file backtrace.log (gdb) set logging on Copying output to backtrace.log. (gdb) bt #0 0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6 ... (gdb) set logging off Done logging to backtrace.log. (gdb) quit
I tried the "bt full" command as well previously but you were still saying that it was incomplete. I'm at a loss...
(In reply to don quixada from comment #28) > I tried the "bt full" command as well previously but you were still saying > that it was incomplete. I'm at a loss... When you type 'bt full', has it actually crashed yet?
Ok I did it again with bt full: https://pastebin.com/9fstt8y7 The full sequence of commands and output (sans the bt itself) is as follows: $ gdb -q /usr/bin/qbittorrent Reading symbols from /usr/bin/qbittorrent... Reading symbols from /usr/lib/debug//usr/bin/qbittorrent.debug... (gdb) run Starting program: /usr/bin/qbittorrent [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff2c8e640 (LWP 14902)] [New Thread 0x7fffebfff640 (LWP 14910)] [New Thread 0x7fffeb7fe640 (LWP 14911)] [New Thread 0x7fffeaffd640 (LWP 14912)] [New Thread 0x7fffea7fc640 (LWP 14913)] [New Thread 0x7fffe9ffb640 (LWP 14914)] [New Thread 0x7fffe97fa640 (LWP 14915)] [New Thread 0x7fffe8ff9640 (LWP 14916)] [New Thread 0x7fffcbfff640 (LWP 14917)] [New Thread 0x7fffc9cae640 (LWP 14919)] [New Thread 0x7fffc94ad640 (LWP 14920)] [New Thread 0x7fffc8cac640 (LWP 14921)] [New Thread 0x7fffbd536640 (LWP 14922)] [New Thread 0x7fffbcd35640 (LWP 14923)] [New Thread 0x7fffa7fff640 (LWP 14924)] [New Thread 0x7fff9ffff640 (LWP 14925)] [New Thread 0x7fffa77fe640 (LWP 14926)] [New Thread 0x7fffa6ffd640 (LWP 14927)] [New Thread 0x7fffa67fc640 (LWP 14928)] [New Thread 0x7fffa5ffb640 (LWP 14929)] [New Thread 0x7fffa57fa640 (LWP 14930)] [New Thread 0x7fffa4ff9640 (LWP 14931)] [New Thread 0x7fff9f7fe640 (LWP 14932)] [New Thread 0x7fff9effd640 (LWP 14933)] [New Thread 0x7fff9e7fc640 (LWP 14934)] [New Thread 0x7fff9dffb640 (LWP 14935)] [New Thread 0x7fff9d7fa640 (LWP 14936)] [New Thread 0x7fff9cff9640 (LWP 14937)] [New Thread 0x7fff67fff640 (LWP 14938)] [New Thread 0x7fff677fe640 (LWP 14939)] [New Thread 0x7fff66ffd640 (LWP 14940)] [New Thread 0x7fff667fc640 (LWP 14941)] [New Thread 0x7fff65ffb640 (LWP 14942)] [New Thread 0x7fff657fa640 (LWP 14943)] [New Thread 0x7fff64ff9640 (LWP 14944)] [New Thread 0x7fff47fff640 (LWP 14945)] [New Thread 0x7fff477fe640 (LWP 14946)] [Detaching after fork from child process 14965] [Detaching after fork from child process 14966] QIODevice::write (QTcpSocket): device not open [Thread 0x7fff9e7fc640 (LWP 14934) exited] [Thread 0x7fff9effd640 (LWP 14933) exited] [Thread 0x7fff9f7fe640 (LWP 14932) exited] [Thread 0x7fffa4ff9640 (LWP 14931) exited] [Thread 0x7fff477fe640 (LWP 14946) exited] [Thread 0x7fff657fa640 (LWP 14943) exited] [Thread 0x7fff64ff9640 (LWP 14944) exited] [Thread 0x7fff65ffb640 (LWP 14942) exited] [Thread 0x7fff667fc640 (LWP 14941) exited] [Thread 0x7fff66ffd640 (LWP 14940) exited] [Thread 0x7fff677fe640 (LWP 14939) exited] [Thread 0x7fff67fff640 (LWP 14938) exited] [Thread 0x7fff9cff9640 (LWP 14937) exited] [Thread 0x7fff9d7fa640 (LWP 14936) exited] Thread 5 "Network" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeaffd640 (LWP 14912)] 0x00007ffff7baee10 in boost::asio::detail::reactive_socket_service_base::close (ec=..., impl=..., this=0x7fffe0131) at /usr/include/boost/asio/detail/impl/reactive_socket_service_base.ipp:109 109 reactor_.deregister_descriptor(impl.socket_, impl.reactor_data_, (gdb) set logging file backtrace.log (gdb) set logging on Copying output to backtrace.log. Copying debug output to backtrace.log. (gdb) bt full [...] (gdb) kill Kill the program being debugged? (y or n) y [Inferior 1 (process 14893) killed] (gdb) set logging off Done logging to backtrace.log. (gdb) quit Note that I had to kill it because the GUI was still on the screen (albeit frozen). Let me know if there was something else I should have done to get more bt information.
I did not managed to reproduce it, but I do run ~amd64 here. Can you tell me that your system is in fact fully updated, and there's no updates pending? Also, this is a long shot, but could you try to rebuild libtorrent-rasterbar and qbittorrent without specifing march=native like you do now?
It was up to date as of a couple of days ago. I'm currently updating (-uD) some packages now so it will be fully up-to-date again shortly. As far as the march setting. I can change it. Do you mean remove '-march=native' completely? Or put '-march=' or '-march=athlon64' or something else? Also, after I change this flag, do I need to run an 'emerge --changed-use @world' update?
Ok, no difference after a system update and rebuild of qbit. I outputted another backtrace that appears to be more extensive: https://pastebin.com/E2pU5vWU Also, the upstream bug thread, he was asking for the "stacktrace", is this the same thing as "backtrace"? (I looked it up on wikipedia and it appears so but if you can confirm this is the case for Gentoo that would be appreciated.) I will try to build qbit with "march=" and see what happens.
Ok so, using "-march=" I wasn't able to emerge anything. But I tried removing the flag altogether and I could build libtorrent-rasterbar and qbittorrent. After installing, there was no difference, the program still crashed. Here is its bt (command: thread apply all bt full) output: https://pastebin.com/tZbx71RR Incidentally, I've been getting this error when I've been emerging ever since I rebuilt my Gentoo system from scratch back in Oct: setlocale: unsupported locale setting setlocale: unsupported locale setting I've been trying to fix it but so far nothing is working. I'm not sure if it has anything to do with my qbit problem though... ??
Might be worth a shot to see if it happens with locales set to default. To fix your setlocale issue follow https://wiki.gentoo.org/wiki/Localization/Guide and make sure you have generated locales that you set. Try the following in shell. First shutdown qbittorrent and then run export LANG=C LC_CTYPE=C LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=C LC_IDENTIFICATION=C LC_ALL=C qbittorrent This will run qbittorrent with default locales. This is a long shot but we did recently had unrelated issue with another package (borgbackup) crashing due to locale, might be worth a try.
Yeah, it didn't make any difference to do this. Also, I can't tell you how many times in the past I've read that localization guide to fix this problem. I guess will post on the forums about it.
*** This bug has been marked as a duplicate of bug 868480 ***
