mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
SIGSEGV when starting qBittorrent #7734
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#7734
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 @cesarizu on GitHub (Sep 11, 2018).
qBittorrent version and Operating System
If on linux, libtorrent and Qt version
What is the problem
After starting qbitorrent it crashes:
What is the expected behavior
Not crashing 😁
Steps to reproduce
Add any torrent, start it.
Extra info(if any)
Nothing
@cesarizu commented on GitHub (Sep 11, 2018):
This is the backtrace when running through gdb:
Is this an libtorrent error?
@zeule commented on GitHub (Sep 11, 2018):
or the boost one.
@nathanmkaya commented on GitHub (Sep 12, 2018):
I'm facing the same error.
I guess it's a boost caused error since Tumbleweed received an update for boost recently
@akontsevich commented on GitHub (Sep 13, 2018):
I have same in Tumbleweed:
Whether somebody filed the bug to openSUSE?
@carlazz66 commented on GitHub (Sep 13, 2018):
qBittorrent version: v4.1.2
Caught signal: SIGSEGV
Stack trace:
/usr/lib64/libtorrent-rasterbar.so.9 : ()+0x180f95 [0x7f0f938f0f95]
/usr/lib64/libtorrent-rasterbar.so.9 : ()+0x2f9603 [0x7f0f93a69603]
/usr/lib64/libtorrent-rasterbar.so.9 : ()+0x1d3eb8 [0x7f0f93943eb8]
/usr/lib64/libtorrent-rasterbar.so.9 : ()+0xeb56f [0x7f0f9385b56f]
/lib64/libpthread.so.0 : ()+0x7554 [0x7f0f93557554]
/lib64/libc.so.6 : clone()+0x3f [0x7f0f91a9accf]
Segmentation fault (core dumped)
@carlazz66 commented on GitHub (Sep 13, 2018):
Exactly the same!
@olegantonyan commented on GitHub (Sep 13, 2018):
A very dirty hack to reanimate qbittorrent until the issue is fixed. Pull these libraries
from Leap http://download.opensuse.org/distribution/openSUSE-current/repo/oss/x86_64/
Extract
.sofrom their rpms, put in one folder and runLD_LIBRARY_PATH=/path/to/libs qbittorrent@akontsevich commented on GitHub (Sep 13, 2018):
I've rebuilt qbittorrent src package with current boost v1.68 - still crash. So qbittorrent works only with v1.66/1.67? Need to fix/update qbittorrent somehow?
@Chocobo1 commented on GitHub (Sep 14, 2018):
qbt v4.1.2 for windows is built with boost 1.68 without any problems: https://www.qbittorrent.org/download.php
And I haven't seen this issue reported from other linux distros, so maybe file an issue to openSUSE package maintainer?
@zachberger commented on GitHub (Sep 14, 2018):
@olegantonyan would you be willing to zip those up and share them? It would make the work around much easier for others.
@olegantonyan commented on GitHub (Sep 15, 2018):
@zachberger https://yadi.sk/d/LQRpxCAcfTxJDA 64bit libraries for opensuse
@carlazz66 commented on GitHub (Sep 15, 2018):
@olegantonyan many thanks, it work well!
@guoyunhe commented on GitHub (Sep 15, 2018):
I found that the libtorrent in openSUSE is from https://github.com/arvidn/libtorrent , while the version is quit old and need update.
Another libtorrent is https://github.com/arvidn/libtorrent
Which one is the real libtorrent?
@guoyunhe commented on GitHub (Sep 16, 2018):
I reported a bug to openSUSE Bugzilla https://bugzilla.opensuse.org/show_bug.cgi?id=1108567
@XRevan86 commented on GitHub (Sep 16, 2018):
Here's another bugreport worth mentioning: https://github.com/arvidn/libtorrent/issues/3261
I suspect the issue is triggered by Boost 1.68.0 and isn't openSUSE-specific.
@XRevan86 commented on GitHub (Sep 16, 2018):
Boost 1.68.0 introduces some new stuff in the ABI for C++14.
The problem appears when libtorrent-rasterbar is built with -std=c++14 (the default with recent versions of GCC) and qBittorrent is built with C++11.
I am yet to figure out why CMake picks C++11 by default for qBittorrent.
@zeule commented on GitHub (Sep 16, 2018):
@XRevan86, could you check, please, that libtorrent requires C++14 (
pkg-config --cflags libtorrent-rasterbar) and that qBt does not catch that flag? I guess the simplest way would be to type a garbage into one of the qBt source files and look for the compiler output.@XRevan86 commented on GitHub (Sep 16, 2018):
@zeule, no, it doesn't do that.
I am puzzled why qBittorrent with CMake builds with -std=gnu++11 by default (even when
CMAKE_CXX_STANDARDis not set at all). The patch above works, but… why?@zeule commented on GitHub (Sep 16, 2018):
@XRevan86, thanks! But do you confirm that libtorrent contains -std=c++14 in its .pc file?
@XRevan86 commented on GitHub (Sep 16, 2018):
@zeule, no, it doesn't contain that.
libtorrent-rasterbar was actually built with autotools with no explicit
-std.@zeule commented on GitHub (Sep 16, 2018):
Aha! That makes sense then. I can't find documentation entry for the
CMAKE_CXX_STANDARD_COMPUTED_DEFAULTvariable and therefore I would rather not use that.qBt sets the C++ version explicitly because on Windows there is no way for libtorrent to pass the required standard version as there is no pkg-config. Selecting the default or the latest available will not work if compiler defaults to C++17, AFAIK, because libtorrent will still use C++14. There is no other options for us as to follow that behaviour.
@XRevan86 commented on GitHub (Sep 16, 2018):
@zeule, I've got the impression that
CMAKE_CXX_STANDARDis but the minimal requirement, that CMake has no problem with picking up a higher version when it is the default.So, from my understanding, C++14 should have been picked up, for it is the default in GCC 7+.
Even if all that hardcoding is removed from CMakeLists.txt, I still see
-std=gnu++11in the build logs.So what is happening exactly?
@XRevan86 commented on GitHub (Sep 16, 2018):
@zeule, libtorrent-rasterbar doesn't have that hardcode with autotools.
And CMake in libtorrent is not in a complete state, it cannot build the C bindings, for instance (and the Python bindings on the released branch).
@zeule commented on GitHub (Sep 16, 2018):
Do you suggest then to use defaults if
CMAKE_CXX_STANDARD_COMPUTED_DEFAULTvalue is greater or equal to 11?@XRevan86 commented on GitHub (Sep 16, 2018):
@zeule, no, sorry, I didn't account for 98 > 14.
I noticed that Qt5 assumes
-std=gnu++11when building. But I cannot find any place where that translates to CMake.cmake/cmake#17146 suggests that this could be a CMake bug.
@sledgehammer999 commented on GitHub (Sep 16, 2018):
@XRevan86 I assume that your gcc version has by default enabled c++14?
@XRevan86 commented on GitHub (Sep 16, 2018):
@sledgehammer999, yes, GCC 8.2.1.
@sledgehammer999 commented on GitHub (Sep 16, 2018):
@XRevan86 can you try building with the
configurescript instead to see if it also works? From a glance, it should work better than the CMake variant.@zeule commented on GitHub (Sep 16, 2018):
How could it work better when we have
CONFIG += c++11insrc.pro?@zeule commented on GitHub (Sep 16, 2018):
Use C++17 in my fork without a problem.
@sledgehammer999 commented on GitHub (Sep 16, 2018):
My assumption is that QT/qmake requires it as a minimum. Otherwise I need to revise the autotools system too.
@iiv3 commented on GitHub (Sep 17, 2018):
May I propose to remove both
and
The root of the problem is
boost. It is the one that changes its API depending on the selected-stdstandard. It does not providepkg-configon any system, so there is no way to know for sure, what options it needs to work properly.That's why it is best to use the default for the system.
If
libtorrent-rasterbar.pcprovides some-stdoptions, they could be only a guess.If you want to do the right thing, then use this crash and recreate it as
configurecheck.You could even try a number of different known
-std=variants until the test runs successfully.@XRevan86 commented on GitHub (Sep 17, 2018):
@iiv3, I agree that the hardcode of C++11 or of any other version of the standard should not be there, but, unfortunately, for some reason, this doesn't solve this bug as I have observed – CMake keeps explicitly appending
-std=gnu++11.Although with qmake that probably doesn't happen.
@zeule commented on GitHub (Sep 17, 2018):
Keep in mind that qBt code requires at least C++11.
@deelaka commented on GitHub (Sep 18, 2018):
I tried compiling with boost 1.66 and made sure qBt, libtorrent and boost were compiled with C++11, however I'm still hitting a segmentation fault...
@XRevan86 commented on GitHub (Sep 18, 2018):
@deelaka, check
$HOME/.local/share/data/qBittorrent/BT_backup/for an oddly small .fastresume file.ABI-broken qBittorrent creates one when one adds a magnet link, which makes qBittorrent crash later (probably regardless of whether it is broken or not).
@akontsevich commented on GitHub (Sep 18, 2018):
@XRevan86, yes it crashed for me after some new torrent file added to download.
@deelaka commented on GitHub (Sep 18, 2018):
@XRevan86 Unfortunately I cannot confirm about the
.fastresumefile on my compiled version, there is however an emptysession.lockfile in$HOME/.local/share/data/qBittorrent/BT_backup/. But yes the crash occurs when adding a magnet link. I don't think its limited to adding magnet links however. I've noticed the crash occurs when qbitorrent calls libtorrent for whatever reason, be it adding a magnet link or initiating the download of a torrent on application startup.What baffles me the most is the fact that compiling
boost-1.66,libtorrent 1.1.9.0&qbitorrent 4.1.2on C++11 still produces a segmentation fault presumably from due to a ABI issue whereas @olegantonyan's solution presumably works which again loadsboost-1.66libs. But maybe I've made a mistake. Can anyone else confirm compiling withboost-1.66still produce the said seg fault?On another note I happened to come across the patch you submitted on OBS (thanks!). This patch isn't meant to resolve the issue right? It didn't resolve the issue for me at which point I tried compiling.
@XRevan86 commented on GitHub (Sep 18, 2018):
@deelaka, from my observation, a faulty
$HASH.fastresumefile is what causes the start-up crash. If you have any$HASH.fastresumewith no corresponding$HASH.torrent, I take it it can be safely removed (and I bet there is).Yes, it's a hack to fix the issue of producing a broken file when adding a magnet link.
I think you still need to fix the profile…
@deelaka commented on GitHub (Sep 18, 2018):
@XRevan86 Thanks for the reply. I managed to recompile from scratch and now things seem to be in order. Seems like previously I had linked incorrectly. The packages are
boost-1.66,libtorrent 1.1.9.0&qbitorrent 4.1.2.It seems now when I add a torrent and start downloading, it creates the said
$HASH.fastresumeand$HASH.torrentfiles. Previously I was unable to add a torrent to the queue at all and had no previous torrents in the queue and even though it did crash when adding a torrent it did not make a small$HASH.fastresumefile of the torrent, probably because it crashes before you can add it to the queue. Also I didn't experience a crash on startup, it was only when adding a torrent, maybe startup crashes happen if you had torrents added previously.@akontsevich commented on GitHub (Sep 19, 2018):
Seems SUSE have fixed this with recent upgrade. Works fine!
@nathanmkaya commented on GitHub (Sep 19, 2018):
Yes they have
@Chocobo1 commented on GitHub (Nov 1, 2018):
Closing as fixed.@iiv3 commented on GitHub (Nov 2, 2018):
No, it is not fixed.
By default qBIttorrent would still add -std=c++11 and that would break when libtorrent-rastarbar and boost are compiled with default settings.
@iiv3 commented on GitHub (Nov 8, 2018):
I just want to point out that the commit does fix the segfault for the case when qBittorrent is compiled with CMake.
If autoconf tools are used (aka
configure) the-std=C++11is still inserted. Its source is fromsrc/src.pro:Removing it would fix the issue, but I guess you'd need to add
configurecheck if the compiler supports at least C++11.@iiv3 commented on GitHub (Nov 19, 2018):
Compiling 4.1.4 I hit that bug again.
The
src/src.prolines have not been removed and they still force C++11 even through nowconfiguredoes have proper mode detection.@theluke commented on GitHub (Mar 6, 2020):
I had the same problem, I installed libtorrent-rasterbat10, removed 9 and also installed libtorrent-rasterbar-dbg and qbittorrent-dbg. All is good now