Closed WestonHanners closed 3 years ago
Leaving more info here, I checked the qbittorrent logs and it seems to crash just after firing up the webui.
I am investigating a potential libssl mismatch.
Does it look anything like this?
https://github.com/arvidn/libtorrent/issues/5324
Specifically this
qBittorrent version: v4.3.1
Caught signal: SIGSEGV
Stack trace:
qbittorrent-nox : libtorrent::dht::traversal_algorithm::add_entry(libtorrent::digest32<160l> const&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::dht::observer_flags_tag, void>)+0x8d2 [0x56483bd5d212]
qbittorrent-nox : ()+0x4f2538 [0x56483bd5d538]
qbittorrent-nox : libtorrent::dht::look_for_nodes(char const*, boost::asio::ip::udp const&, libtorrent::bdecode_node const&, std::function<void (libtorrent::dht::node_endpoint const&)>)+0x190 [0x56483bd5b5f0]
qbittorrent-nox : libtorrent::dht::traversal_observer::reply(libtorrent::dht::msg const&)+0x142 [0x56483bd5b862]
qbittorrent-nox : libtorrent::dht::find_data_observer::reply(libtorrent::dht::msg const&)+0x20b [0x56483be0ae7b]
qbittorrent-nox : libtorrent::dht::get_peers_observer::reply(libtorrent::dht::msg const&)+0x1aa [0x56483be0ee6a]
qbittorrent-nox : libtorrent::dht::rpc_manager::incoming(libtorrent::dht::msg const&, libtorrent::digest32<160l>*)+0x760 [0x56483bd58170]
qbittorrent-nox : libtorrent::dht::node::incoming(libtorrent::aux::listen_socket_handle const&, libtorrent::dht::msg const&)+0x20f [0x56483bd4548f]
qbittorrent-nox : libtorrent::dht::dht_tracker::incoming_packet(libtorrent::aux::listen_socket_handle const&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, libtorrent::span<char const>)+0x319 [0x56483bd38859]
qbittorrent-nox : libtorrent::aux::session_impl::on_udp_packet(std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, boost::system::error_code const&)+0xd9a [0x56483bc0641a]
qbittorrent-nox : boost::asio::detail::reactive_null_buffers_op<libtorrent::aux::allocating_handler<std::_Bind<std::_Mem_fn<void (libtorrent::aux::session_impl::*)(std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, boost::system::error_code const&)> (libtorrent::aux::session_impl*, std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, std::_Placeholder<1>)>, 400ul> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x105 [0x56483bc31035]
qbittorrent-nox : boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x1e6 [0x56483bc1ce36]
qbittorrent-nox : ()+0x3674d8 [0x56483bbd24d8]
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 : ()+0xb9e6f [0x7fc0a0253e6f]
/lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x74a4 [0x7fc0a07274a4]
/lib/x86_64-linux-gnu/libc.so.6 : clone()+0x3f [0x7fc09f9c8d0f]
Segmentation fault
The timing looks correct, but my *nix-fu is a little rusty, how do I get a stack trace out of this thing?
When you see that in qbittorrent, that is the stack trace.
If you need to use gdb
do apt-get install gdb
.
Start gdb using the command gdb
then type file path/bin
But really all you need to do it confirm you see the same thing i posted.
it looks like I am not getting a symbolicated stack trace.
Reading symbols from /usr/local/bin/qbittorrent-nox...(no debugging symbols found)...done.
(gdb) continue
The program is not being run.
(gdb) run
Starting program: /usr/local/bin/qbittorrent-nox
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
*** Legal Notice ***
qBittorrent is a file sharing program. When you run a torrent, its data will be made available to others by means of upload. Any content you share is your sole responsibility.
No further notices will be issued.
Press 'y' key to accept and continue...
y
[New LWP 19072]
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
[New LWP 19073]
[New LWP 19074]
[New LWP 19075]
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
[New LWP 19076]
[New LWP 19077]
[New LWP 19078]
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
[New LWP 19079]
Thread 8 "Thread (pooled)" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 19078]
0x76345df0 in ?? ()
(gdb) backtrace
#0 0x76345df0 in ?? ()
#1 0x74cd7134 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
if you are building this locally, then try adding one of these to the libtorrent b2 build command.
variant=debug
or
debug-symbols=on
but what do you actually see when after you run qbittorrent and press Y normally?
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
*** Legal Notice ***
qBittorrent is a file sharing program. When you run a torrent, its data will be made available to others by means of upload. Any content you share is your sole responsibility.
No further notices will be issued.
Press 'y' key to accept and continue...
y
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
The legacy data directory '/home/qbittorrent/.local/share/data/qBittorrent/' is used. It is recommended to move its content to '/home/qbittorrent/.local/share/qBittorrent/'
*************************************************************
Please file a bug report at http://bug.qbittorrent.org and provide the following information:
qBittorrent version: v4.3.1
Caught signal: SIGSEGV
Stack trace:
There were no function names found in the stack trace
.Seems like debug symbols are not installed, and the stack trace is useless.
Segmentation fault
What is the build platform OS?
Raspberry Pi OS Lite Release date: December 2nd 2020 Kernel version: 5.4
For libtorrent add this
variant=debug
or
debug-symbols=on
For qbitorrent add this
--enable-debug
Build again and let's see?
ok, it will take couple hours. I will get back to you
In the meantime, do any of the static images here work?
https://github.com/userdocs/qbittorrent-nox-static/releases/tag/release-4.3.1_v1.2.11
The thinking here is this, if they also fail, i can build you a static image with debug symbols quickly, just to get a stack trace of the issue.
I don't expect they will work on Arm7 architecture, right?
oh yeah, i need to build on arm7 32bit?
that is correct
Maybe i can do it with qemu https://qemu.readthedocs.io/en/latest/system/target-arm.html
Build is underway. libboost is the most time-consuming part. if you get a qemu build, I will be quite happy to try that.
side topic, how did you end up resolving this? it might be worth me investigating from that angle.
Does it look anything like this?
Specifically this
qBittorrent version: v4.3.1 Caught signal: SIGSEGV Stack trace: qbittorrent-nox : libtorrent::dht::traversal_algorithm::add_entry(libtorrent::digest32<160l> const&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::dht::observer_flags_tag, void>)+0x8d2 [0x56483bd5d212] qbittorrent-nox : ()+0x4f2538 [0x56483bd5d538] qbittorrent-nox : libtorrent::dht::look_for_nodes(char const*, boost::asio::ip::udp const&, libtorrent::bdecode_node const&, std::function<void (libtorrent::dht::node_endpoint const&)>)+0x190 [0x56483bd5b5f0] qbittorrent-nox : libtorrent::dht::traversal_observer::reply(libtorrent::dht::msg const&)+0x142 [0x56483bd5b862] qbittorrent-nox : libtorrent::dht::find_data_observer::reply(libtorrent::dht::msg const&)+0x20b [0x56483be0ae7b] qbittorrent-nox : libtorrent::dht::get_peers_observer::reply(libtorrent::dht::msg const&)+0x1aa [0x56483be0ee6a] qbittorrent-nox : libtorrent::dht::rpc_manager::incoming(libtorrent::dht::msg const&, libtorrent::digest32<160l>*)+0x760 [0x56483bd58170] qbittorrent-nox : libtorrent::dht::node::incoming(libtorrent::aux::listen_socket_handle const&, libtorrent::dht::msg const&)+0x20f [0x56483bd4548f] qbittorrent-nox : libtorrent::dht::dht_tracker::incoming_packet(libtorrent::aux::listen_socket_handle const&, boost::asio::ip::basic_endpoint<boost::asio::ip::udp> const&, libtorrent::span<char const>)+0x319 [0x56483bd38859] qbittorrent-nox : libtorrent::aux::session_impl::on_udp_packet(std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, boost::system::error_code const&)+0xd9a [0x56483bc0641a] qbittorrent-nox : boost::asio::detail::reactive_null_buffers_op<libtorrent::aux::allocating_handler<std::_Bind<std::_Mem_fn<void (libtorrent::aux::session_impl::*)(std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, boost::system::error_code const&)> (libtorrent::aux::session_impl*, std::weak_ptr<libtorrent::aux::session_udp_socket>, std::weak_ptr<libtorrent::aux::listen_socket_t>, libtorrent::aux::transport, std::_Placeholder<1>)>, 400ul> >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x105 [0x56483bc31035] qbittorrent-nox : boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)+0x1e6 [0x56483bc1ce36] qbittorrent-nox : ()+0x3674d8 [0x56483bbd24d8] /usr/lib/x86_64-linux-gnu/libstdc++.so.6 : ()+0xb9e6f [0x7fc0a0253e6f] /lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x74a4 [0x7fc0a07274a4] /lib/x86_64-linux-gnu/libc.so.6 : clone()+0x3f [0x7fc09f9c8d0f] Segmentation fault
It is currently unresolved. The nature of the problem is not understood. If it turns out to be the same issue it appears hardware related.
still building, but in the meantime, I found this
https://github.com/qbittorrent/qBittorrent/issues/12632
I wonder if it's related
There is also this linked in my issue, https://github.com/arvidn/libtorrent/issues/4625
it's worth mentioning that the package in the repository works without issue (aside from bugs that have since been patched). so it's possible to run on the platform.
If this is boost/libtorrent related it appears to be in the other it's not the same.
Oops, here is the rest,
https://packages.debian.org/buster/libtorrent-rasterbar9
v1.1, we are using v1.2. We can't compare these.
I was trying to confirm the package version on my pi, but while it's compiling, it's basically unusable. I might have to get another one just for staging / compiling.
As far as i understand it, Raspberry Pi OS is based on Debian, Stretch or Buster. So whatever the related package is there.
cat /etc/os-release
should provide some info.
cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
managed to squeeze that command through.
So are you saying your script uses version 1.2 of libtorrent-rasterbar? and since the package version is 1.2 (which works) the issue might be there?
I wonder if I change line 77 in your script
libtorrent_version='1.2' # Set this here so it is easy to see and change
to 1.1, would that work, or does qbittorrent latest currently require 1.2 and this is not gonna work.
That would actually just break everything and the default version of qbittorrent (4.3.1) does not support it. There is a correct way to do it using flags.
script.sh all -lt RC_1_2 -qt release-4.2.5
But what are you gaining from that? I think it's better to get the debug and see.
I know for this builds find on a amd64 debian buster so the problem seems related to hardware/arch type.
Possibly, I'm going to wait and see. Surely this compile shouldn't take much longer.
in the meantime, I have continued my rabbit hole excursion.
https://github.com/arvidn/libtorrent/issues/5117#issuecomment-689054317
Possibly related, but he uses cmake where i use b2 (libtorrent) and cmake where i use qmake (qbittorrent). so it's not necessarily related. Hopefully the debug info is helpful
So... you won't believe this.
two builds and it kept crashing, after adding debug, now it runs.
It's looking more an more like this issue, https://github.com/qbittorrent/qBittorrent/issues/11882#issuecomment-575096767
I'm going to try another build at some point this week with my script changes reverted just to try and isolate the issue. I was messing with QT versions in between builds.
2 things.
1: You can now toggle debug builds using the flag -d
from the latest pull request.
2: The weird thing about this is I could move to another platform and the build would not segfault. The fault seems linked to a platform feature I have not identified and not a fault in the build. The CPU/arch seems like the most likely culprit. but it may be something else.
The changes i just pushed make is so you no longer need to build the boost libs, skipping a large part of the build process for you.
going to try it out again this evening, thanks for the update.
Sorry for no response on this, I am still going to try again, but holidays slowed stuff down, please don't close this yet.
I just rand the build today on my Rpi 4, only change i made to the script was reduce the amount of threads used.
added the function below here near the top. (you could also change the ignore to 1 if you want) This makes the script use the function over the binary directly and prevents the usage of all 4 threads. instead it ignores the amount of threads that you specify.
So in the case of the Pi4, it is a quad core, so the command nproc would give back the number 4. And the build script uses make -j $(nproc)
, it would then use 4 threads. I found that this made the Pi4 unstable and unresponsive during the build. And adding this small thing would keep it responsive at the expense of possibly making the build take longer.
function nproc() {
/usr/bin/nproc --ignore=2
}
Added that near the start. If i didnt do that, it would slow the build and the Pi down to a crawl and nothing would respond anymore.
I dont believe this changed the build any, but thought id mention it anyway.
Beyond that. The build ran fine and its now running. No crashes yet, will report back if that happens.
And the Pi4 i built it on is a Raspberry Pi 4 2GB running with Dietpi v6.34.3 (which is basically default raspbian with a few scripts added and small things removed)
processor : 0
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 180.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
Linux 5.4.83-v7l+ #1379 SMP Mon Dec 14 13:11:54 GMT 2020 armv7l GNU/Linux
Also compiled 4.3.3 with this on the raspberry pi with no issues so far.
Can you provide specifics of the model and version you have?
Did that in my previous post, ran it on the same pi. Newest update is running fine
Oh yeah. I didn't scroll back.
How does the static build do memory wise on the pi?
There is a simpler script that can be used to build it using shared stuff to compare resource usage and performance.
During light download work it uses about 6.2% of 2GB memory.
@WestonHanners have you resolved this issue?
If not what are the specs of your device?
Just did the build of the latest version 4.3.4.1 on my pi4 with the same modification (to reduce the amount of threads used to build) and it seems to be running fine. Did the build on the same Pi4 as before.
I am willing to share the builds I do for you if you want. Builds take a while cuz pi, but they work fine. Anyone who wants the static build can have it
Can also try a build on 64bit arm if needed
I know it's not written that this is officially supported, but I was able to get this build on my raspberry pi 4. However, when I try to run it, I get a segmentation fault after getting past the disclaimer.
I would like to troubleshoot this, but I am not exactly sure where to begin. I believe I have all the necessary dependencies installed.
If someone could give me a prod in the right direction, I can contribute back anything I discover about getting this running on the pi.