SIGSEGV on Rasbian #29
Comments
|
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? 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 Start gdb using the command 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. |
|
if you are building this locally, then try adding one of these to the libtorrent b2 build command. or |
|
but what do you actually see when after you run qbittorrent and press Y normally? |
|
|
What is the build platform OS? |
|
Raspberry Pi OS Lite |
|
For libtorrent add this or For qbitorrent add this 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.
|
|
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 I wonder if it's related |
|
There is also this linked in my issue, arvidn/libtorrent#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. |
|
As far as i understand it, Raspberry Pi OS is based on Debian, Stretch or Buster. So whatever the related package is there. |
|
|
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 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.
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. |
|
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, qbittorrent/qBittorrent#11882 (comment) |
|
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 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) 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 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)
|
|
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 was thinking to try to use a docker image or something to build arm builds. |
|
@dynosu @WestonHanners please try this arm64 build via github actions |
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.
The text was updated successfully, but these errors were encountered: