Closed AlexCzar closed 3 years ago
Another one in the same distro:
`qBittorrent version: v4.3.8
Caught signal: SIGSEGV
Stack trace:
qbittorrent : ()+0xef262 [0x56391aa63262]
qbittorrent : ()+0xf0b7b [0x56391aa64b7b]
/lib64/libQt5Core.so.5 : QObject::event(QEvent)+0x2ae [0x7fa1c5330fbe]
/lib64/libQt5Widgets.so.5 : QApplicationPrivate::notify_helper(QObject, QEvent)+0x7f [0x7fa1c680ca7f]
/lib64/libQt5Core.so.5 : QCoreApplication::notifyInternal2(QObject, QEvent)+0x12a [0x7fa1c53049ca]
/lib64/libQt5Core.so.5 : QCoreApplicationPrivate::sendPostedEvents(QObject, int, QThreadData*)+0x187 [0x7fa1c5307a17]
/lib64/libQt5Core.so.5 : ()+0x332823 [0x7fa1c535c823]
/lib64/libglib-2.0.so.0 : g_main_context_dispatch()+0x16f [0x7fa1c3fdd82f]
/lib64/libglib-2.0.so.0 : ()+0x56bb8 [0x7fa1c3fddbb8]
/lib64/libglib-2.0.so.0 : g_main_context_iteration()+0x2f [0x7fa1c3fddc6f]
/lib64/libQt5Core.so.5 : QEventDispatcherGlib::processEvents(QFlags
@AlexCzar Very detailed report. Yeah. I'm affected too.
qBittorrent is missing symbols in these stacktraces so we can't see where it crashed.
After running qbittorent
in gdb
I got the following (not sure if it is any more helpful though):
Thread 1 "qbittorrent" received signal SIGSEGV, Segmentation fault.
BitTorrent::Session::handleStateUpdateAlert (p=
Installing the missing separate debuginfos (qbittorrent-debuginfo-4.3.8-1.2.x86_64) gave no additional output.
openSUSE Tumbleweed upgraded libc recently to 2.34, I think that might be the reason. Have you considered reporting it at bugzilla?
openSUSE Tumbleweed upgraded libc recently to 2.34, I think that might be the reason. Have you considered reporting it at bugzilla?
No, I have not reported it. On the apps that I use, there are two that have issues after the update I had a couple of days ago (and yes, it was an update of libc, since around 10000 packages got updated :smile: ). To my understanding this is that the libc is more or less okay, but the two apps might need an update to be working as expected. If you think otherwise, please, help me understand and I will report the issues at https://bugzilla.opensuse.org/index.cgi :wink:
To my understanding this is that the libc is more or less okay, but the two apps might need an update to be working as expected.
Yes, this is probably true. I just suggested bugzilla, because I don't know if it should be fixed on the packaging side, or upstream, but probably upstream.
No, I have not reported it. On the apps that I use, there are two that have issues after the update I had a couple of days ago (and yes, it was an update of libc, since around 10000 packages got updated 😄 ). To my understanding this is that the libc is more or less okay, but the two apps might need an update to be working as expected. If you think otherwise, please, help me understand and I will report the issues at https://bugzilla.opensuse.org/index.cgi 😉
@pmanousis @balping and anyone using openSUSE Tumbleweed Please file an issue to openSUSE anyway. If something is broken due to some updates, they deserve to know the situation too.
Indeed it may be an issue on openSUSE side.
I was having the exact same problem but I found a workaround by installing qBittorrent from the openSUSE:network repo (which is the devel area of Tumbleweed) and it runs ok.
It might be just a matter of refreshing openSUSE:Tumbleweed repo.
EDIT: bugzilla: #1191150
The problem was likely this one, an incompatibility between libtorrent-rasterbar and boost1.77, already addressed:
https://build.opensuse.org/request/show/921546
The update will be out in the next snapshot or two.
@tguruswamy that fix is specific to v2 and the OP is building or using v1.2
It also broke docker so I can't even play around with it: https://stackoverflow.com/questions/69314156/zypper-not-working-in-a-fresh-opensuse-tumbleweed-container
I mean, that was a bold move, updating to glibc 2.34 and probably just derailed things for a bit.
I am going to try a vm and see if my builds work or i can build it.
Yes you are right.
I think glibc-2.34 is not the immediate cause, as the problem appeared a few snapshots later (coincident with the boost1.77 update).
I can also report that loading with no fastresume files works fine.
Not directly but is this not an issue with libc + and libQt5Core? according to the stack traces (if i read them correctly)
Caught signal: SIGSEGV
Stack trace:
qbittorrent-nox : ()+0x7f342 [0x55886aca5342]
qbittorrent-nox : ()+0x8150b [0x55886aca750b]
/lib64/libQt5Core.so.5 : QObject::event(QEvent*)+0x2ae [0x7f4d5d18ffbe]
...
/lib64/libc.so.6 : __libc_start_main()+0x7c [0x7f4d5c99b5ec]
qbittorrent-nox : ()+0x4c4e5 [0x55886ac724e5]
[1] 1834 segmentation fault (core dumped) qbittorrent-nox
The libc call is always there, that's just main(), and all the QEvents are from other threads. I got another user to provide a better stacktrace under gdb (sorry, it's an image), it does seem to be boost allocation related (within the libtorrent fastresume feature):
That package is using libtorrent 1.2 and not 2.04
localhost:/home/username # zypper in qbittorrent
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 2 NEW packages are going to be installed:
libtorrent-rasterbar10 qbittorrent
2 new packages to install.
Overall download size: 7.6 MiB. Already cached: 0 B. After the operation, additional 12.5 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving package libtorrent-rasterbar10-1.2.14-1.3.x86_64 (1/2), 1.3 MiB ( 3.8 MiB unpacked)
Retrieving: libtorrent-rasterbar10-1.2.14-1.3.x86_64.rpm ..........................................................................................................................................................................................................................[done]
Retrieving package qbittorrent-4.3.8-1.2.x86_64 (2/2), 6.3 MiB ( 8.7 MiB unpacked)
Retrieving: qbittorrent-4.3.8-1.2.x86_64.rpm ..........................................................................................................................................................................................................................[done (4.6 MiB/s)]
Checking for file conflicts: ......................................................................................................................................................................................................................................................[done]
(1/2) Installing: libtorrent-rasterbar10-1.2.14-1.3.x86_64 ........................................................................................................................................................................................................................[done]
(2/2) Installing: qbittorrent-4.3.8-1.2.x86_64 ....................................................................................................................................................................................................................................[done]
I will try that debug build and paste a text version.
Also, how do you replicate this issue?
localhost:/home/username # cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20210929"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20210929"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20210929"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"
localhost:/home/username # rpm -q qbittorrent
qbittorrent-4.3.8-1.2.x86_64
localhost:/home/username # qbittorrent-nox
******** Information ********
To control qBittorrent, access the Web UI at http://localhost:8080
The Web UI administrator username is: admin
The Web UI administrator password is still the default one: adminadmin
This is a security risk, please consider changing your password from program preferences.
Works fine
How is boost 1.77 involved here?
I cannot replicate the issue. Can someone explain what I am missing or need to do? As far as i can see this is based on the command
zypper in qbittorrent qbittorrent-nox
And i have OS 20210929
and the op has 20210924
qbittorrent loading a .fastresume file from a running torrent is the condition for the stacktrace I linked. Maybe OP's issue is actually different.
And Tumbleweed 20210924 onwards has boost1.77, so I have to investigate why it still says boost1.76. Presumably something has not rebuilt right but I haven't yet worked out what.
> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20210929"
> rpm -q boost-license1_77_0
boost-license1_77_0-1.77.0-1.1.noarch
OK, i can reproduce it when adding a torrent. With no torrents it loads without errors.
Thread 11 "qbittorrent-nox" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14423]
boost::system::operator== (rhs=..., lhs=...) at /usr/include/boost/system/detail/error_condition.hpp:136
136 return cat_->message( value(), buffer, len );
(gdb) bt
#0 boost::system::operator== (rhs=..., lhs=...) at /usr/include/boost/system/detail/error_condition.hpp:136
#1 boost::system::operator== (rhs=..., lhs=...) at /usr/include/boost/system/detail/error_condition.hpp:134
#2 boost::system::error_category::equivalent (this=<optimized out>, code=<optimized out>, condition=...) at /usr/include/boost/system/detail/error_category_impl.hpp:35
#3 0x00007ffff7ea9105 in boost::system::operator==(boost::system::error_code const&, boost::system::error_condition const&) [clone .constprop.0] (code=..., condition=...) at /usr/include/boost/system/detail/error_code.hpp:315
#4 0x00007ffff7ddfa60 in boost::system::operator!= (rhs=..., lhs=...) at /usr/include/boost/system/detail/error_code.hpp:337
#5 libtorrent::default_storage::initialize (this=0x7fffe801bd10, ec=...) at /usr/src/debug/libtorrent-rasterbar-1-1.2.14-1.3.x86_64/src/storage.cpp:293
#6 0x00007ffff7cc7d67 in libtorrent::disk_io_thread::do_check_fastresume (this=0x555555c310c0, j=0x7fffe8032e80) at /usr/include/c++/11/bits/shared_ptr_base.h:1295
#7 0x00007ffff7cc69d3 in libtorrent::disk_io_thread::perform_job (completed_jobs=..., j=0x7fffe8032e80, this=0x555555c310c0) at /usr/src/debug/libtorrent-rasterbar-1-1.2.14-1.3.x86_64/src/disk_io_thread.cpp:1190
#8 libtorrent::disk_io_thread::execute_job (this=0x555555c310c0, j=0x7fffe8032e80) at /usr/src/debug/libtorrent-rasterbar-1-1.2.14-1.3.x86_64/src/disk_io_thread.cpp:3076
#9 0x00007ffff7cb116e in libtorrent::disk_io_thread::thread_fun (pool=..., queue=..., this=0x555555c310c0) at /usr/src/debug/libtorrent-rasterbar-1-1.2.14-1.3.x86_64/src/disk_io_thread.cpp:3179
#10 libtorrent::disk_io_thread::job_queue::thread_fun (this=<optimized out>, pool=..., work=...) at /usr/src/debug/libtorrent-rasterbar-1-1.2.14-1.3.x86_64/include/libtorrent/disk_io_thread.hpp:402
#11 0x00007ffff7cc924c in std::__invoke_impl<void, void (libtorrent::pool_thread_interface::*)(libtorrent::disk_io_thread_pool&, boost::asio::io_context::work), libtorrent::pool_thread_interface*, std::reference_wrapper<libtorrent::disk_io_thread_pool>, boost::asio::io_context::work> (__f=<optimized out>, __t=<optimized out>, __f=<optimized out>, __t=<optimized out>) at /usr/include/c++/11/bits/invoke.h:74
#12 std::__invoke<void (libtorrent::pool_thread_interface::*)(libtorrent::disk_io_thread_pool&, boost::asio::io_context::work), libtorrent::pool_thread_interface*, std::reference_wrapper<libtorrent::disk_io_thread_pool>, boost::asio::io_context::work> (__fn=<optimized out>)
at /usr/include/c++/11/bits/invoke.h:96
#13 std::thread::_Invoker<std::tuple<void (libtorrent::pool_thread_interface::*)(libtorrent::disk_io_thread_pool&, boost::asio::io_context::work), libtorrent::pool_thread_interface*, std::reference_wrapper<libtorrent::disk_io_thread_pool>, boost::asio::io_context::work> >::_M_invoke<0ul, 1ul, 2ul, 3ul> (this=<optimized out>) at /usr/include/c++/11/bits/std_thread.h:253
#14 std::thread::_Invoker<std::tuple<void (libtorrent::pool_thread_interface::*)(libtorrent::disk_io_thread_pool&, boost::asio::io_context::work), libtorrent::pool_thread_interface*, std::reference_wrapper<libtorrent::disk_io_thread_pool>, boost::asio::io_context::work> >::operator() (this=<optimized out>) at /usr/include/c++/11/bits/std_thread.h:260
#15 std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (libtorrent::pool_thread_interface::*)(libtorrent::disk_io_thread_pool&, boost::asio::io_context::work), libtorrent::pool_thread_interface*, std::reference_wrapper<libtorrent::disk_io_thread_pool>, boost::asio::io_context::work> > >::_M_run (this=<optimized out>) at /usr/include/c++/11/bits/std_thread.h:211
#16 0x00007ffff6ff5cf4 in std::execute_native_thread_routine (__p=0x7fffe8034470) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#17 0x00007ffff6ca3acf in start_thread (arg=<optimized out>) at pthread_create.c:434
#18 0x00007ffff6d282c0 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
I also saw this https://github.com/qbittorrent/qBittorrent/issues/15512#issuecomment-932799174 but i forgot to backtrace it. When i see it again i'll update the post.
@tgregerson looking at this https://build.opensuse.org/package/show/openSUSE:Factory/qbittorrent being built 1 month ago but boost was updated to 1.77 12 days ago
Does the maintainer not just need to trigger a rebuild to build against 1.77 as it looks like it's built with 1.76 and linking to 1.77
Is that not the problem?
I have come to the same conclusion (I am an openSUSE maintainer, though not for this package). This is supposed to happen automatically, I think this is a bug in our build system.
Thanks for investigating, in the end I don't think there's any upstream issue.
For any openSUSE users reading, the workaround until we release a fixed package is to use qbittorrent from the development project, which has been rebuilt against boost1.77
https://software.opensuse.org/download/package?package=qbittorrent&project=network
Just for the context: after recent boost update to 1.77 qbittorent started crashing. But I was able to compile the same versions of libtorrent-rasterbar 1.2.14 and qbittorent 4.3.4 against boost 1.77 without any problems and now qbittorrent is working
The version in the Tumbleweed main repo is now (re)built correctly against boost1.77. The issue is that because boost is header-only, with no library dependency in the final binary, the automatic build system doesn't detect that qbittorrent needed a rebuild. We will try to work out a solution, but the immediate problem is fixed.
qbittorrent-4.3.8-1.3
openSUSE Tumbleweed 20211008
The main boost dep is with libtorrent? That can use just the headers but builds the libs on install libboost-system.so
for example. I'm not sure what qbittorrent does with boost to be honest.
b2 --with-system
would also just build boost-system and skip all other modules if needed
I think it's better to use libtorrent for that check
qBittorrent & operating system versions
qBittorrent: 4.3.8 x64 Operating system: Opensuse Tumbleweed 20210924 Qt: 5.15.2 libtorrent-rasterbar: 1.2.14
What is the problem?
Steps to reproduce
Additional context
Nothing to add here, it started after I updated to the mentioned OS version yesterady.
Log(s) & preferences file(s)
Prefs
Logs