New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SIGSEGV when starting qBittorrent #9485

Open
cesarizu opened this Issue Sep 11, 2018 · 42 comments

Comments

Projects
None yet
@cesarizu

cesarizu commented Sep 11, 2018

qBittorrent version and Operating System

  • qBittorrent version: v4.1.2
  • openSUSE Tumbleweed 4.18.5-1-default x86_64 GNU/Linux

If on linux, libtorrent and Qt version

  • libtorrent-rasterbar9-1.1.8
  • libtorrent19-0.13.6
  • libqt5-5.11.1

What is the problem

After starting qbitorrent it crashes:

qt5ct: using qt5ct plugin
qt5ct: D-Bus global menu: no
qt5ct: D-Bus system tray: no
qt5ct: custom style sheet is disabled


*************************************************************
Please file a bug report at http://bug.qbittorrent.org and provide the following information:

qBittorrent version: v4.1.2

Caught signal: SIGSEGV
Stack trace:
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x180f95  [0x7fac11e4cf95]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x2f9603  [0x7fac11fc5603]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x1d3eb8  [0x7fac11e9feb8]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0xeb56f  [0x7fac11db756f]
  /lib64/libpthread.so.0 : ()+0x7554  [0x7fac11ab4554]
  /lib64/libc.so.6 : clone()+0x3f  [0x7fac100cbccf]
[1]    18306 segmentation fault (core dumped)  qbittorrent

What is the expected behavior

Not crashing 😁

Steps to reproduce

Add any torrent, start it.

Extra info(if any)

Nothing

@cesarizu

This comment has been minimized.

Show comment
Hide comment
@cesarizu

cesarizu Sep 11, 2018

This is the backtrace when running through gdb:

#0  0x00007fcb508b9f95 in boost::system::error_code::message[abi:cxx11]() const (this=0x7fcb43c00c60) at /usr/include/boost/system/error_code.hpp:674
#1  libtorrent::peer_connection::on_receive_data_nb(boost::system::error_code const&, unsigned long) () at ../../src/peer_connection.cpp:6013
#2  0x00007fcb50a32603 in boost::function2<void, boost::system::error_code const&, unsigned long>::operator() (a1=<optimized out>, a0=..., 
    this=0x7fcb43c00c40) at /usr/include/boost/function/function_template.hpp:682
#3  boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> >::operator()<boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list0> (a=<synthetic pointer>..., f=..., this=0x7fcb43c00c60) at /usr/include/boost/bind/bind.hpp:319
#4  boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >::operator() (this=0x7fcb43c00c40) at /usr/include/boost/bind/bind.hpp:1294
#5  boost::asio::asio_handler_invoke<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (function=...) at /usr/include/boost/asio/handler_invoke_hook.hpp:69
#6  boost_asio_handler_invoke_helpers::invoke<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >, boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (context=..., function=...)
    at /usr/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#7  boost::asio::detail::handler_work<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >, boost::asio::system_executor>::complete<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (this=<synthetic pointer>, handler=..., function=...) at /usr/include/boost/asio/detail/handler_work.hpp:82
#8  boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > >::do_complete (owner=0x55eb19190070, base=<optimized out>)
    at /usr/include/boost/asio/detail/completion_handler.hpp:70
#9  0x00007fcb5090ceb8 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=0, ec=..., owner=0x55eb19190070, this=<optimized out>)
    at /usr/include/boost/asio/detail/scheduler_operation.hpp:40
#10 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x55eb19190070)
    at /usr/include/boost/asio/detail/impl/scheduler.ipp:401
#11 boost::asio::detail::scheduler::run (ec=..., this=0x55eb19190070) at /usr/include/boost/asio/detail/impl/scheduler.ipp:154
#12 boost::asio::io_context::run (this=<optimized out>) at /usr/include/boost/asio/impl/io_context.ipp:62
#13 0x00007fcb5082456f in boost::asio::detail::boost_asio_detail_posix_thread_function (arg=0x55eb191a1460)
    at /usr/include/boost/asio/detail/impl/posix_thread.ipp:74
#14 0x00007fcb50521554 in start_thread () from /lib64/libpthread.so.0
#15 0x00007fcb4eb38ccf in clone () from /lib64/libc.so.6

Is this an libtorrent error?

cesarizu commented Sep 11, 2018

This is the backtrace when running through gdb:

#0  0x00007fcb508b9f95 in boost::system::error_code::message[abi:cxx11]() const (this=0x7fcb43c00c60) at /usr/include/boost/system/error_code.hpp:674
#1  libtorrent::peer_connection::on_receive_data_nb(boost::system::error_code const&, unsigned long) () at ../../src/peer_connection.cpp:6013
#2  0x00007fcb50a32603 in boost::function2<void, boost::system::error_code const&, unsigned long>::operator() (a1=<optimized out>, a0=..., 
    this=0x7fcb43c00c40) at /usr/include/boost/function/function_template.hpp:682
#3  boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> >::operator()<boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list0> (a=<synthetic pointer>..., f=..., this=0x7fcb43c00c60) at /usr/include/boost/bind/bind.hpp:319
#4  boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >::operator() (this=0x7fcb43c00c40) at /usr/include/boost/bind/bind.hpp:1294
#5  boost::asio::asio_handler_invoke<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (function=...) at /usr/include/boost/asio/handler_invoke_hook.hpp:69
#6  boost_asio_handler_invoke_helpers::invoke<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >, boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (context=..., function=...)
    at /usr/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#7  boost::asio::detail::handler_work<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > >, boost::asio::system_executor>::complete<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > > (this=<synthetic pointer>, handler=..., function=...) at /usr/include/boost/asio/detail/handler_work.hpp:82
#8  boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::function2<void, boost::system::error_code const&, unsigned long>, boost::_bi::list2<boost::_bi::value<boost::system::error_code>, boost::_bi::value<unsigned long> > > >::do_complete (owner=0x55eb19190070, base=<optimized out>)
    at /usr/include/boost/asio/detail/completion_handler.hpp:70
#9  0x00007fcb5090ceb8 in boost::asio::detail::scheduler_operation::complete (bytes_transferred=0, ec=..., owner=0x55eb19190070, this=<optimized out>)
    at /usr/include/boost/asio/detail/scheduler_operation.hpp:40
#10 boost::asio::detail::scheduler::do_run_one (ec=..., this_thread=..., lock=..., this=0x55eb19190070)
    at /usr/include/boost/asio/detail/impl/scheduler.ipp:401
#11 boost::asio::detail::scheduler::run (ec=..., this=0x55eb19190070) at /usr/include/boost/asio/detail/impl/scheduler.ipp:154
#12 boost::asio::io_context::run (this=<optimized out>) at /usr/include/boost/asio/impl/io_context.ipp:62
#13 0x00007fcb5082456f in boost::asio::detail::boost_asio_detail_posix_thread_function (arg=0x55eb191a1460)
    at /usr/include/boost/asio/detail/impl/posix_thread.ipp:74
#14 0x00007fcb50521554 in start_thread () from /lib64/libpthread.so.0
#15 0x00007fcb4eb38ccf in clone () from /lib64/libc.so.6

Is this an libtorrent error?

@zeule

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 11, 2018

Contributor

or the boost one.

Contributor

zeule commented Sep 11, 2018

or the boost one.

@nathanmkaya

This comment has been minimized.

Show comment
Hide comment
@nathanmkaya

nathanmkaya 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

nathanmkaya commented 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

This comment has been minimized.

Show comment
Hide comment
@akontsevich

akontsevich Sep 13, 2018

I have same in Tumbleweed:

qBittorrent version: v4.1.2

Caught signal: SIGSEGV
Stack trace:
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x180f95  [0x7f10614a8f95]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x2f9603  [0x7f1061621603]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x1d3eb8  [0x7f10614fbeb8]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0xeb56f  [0x7f106141356f]
  /lib64/libpthread.so.0 : ()+0x7554  [0x7f106110f554]
  /lib64/libc.so.6 : clone()+0x3f  [0x7f105f652ccf]
Ошибка сегментирования (стек памяти сброшен на диск)

Whether somebody filed the bug to openSUSE?

akontsevich commented Sep 13, 2018

I have same in Tumbleweed:

qBittorrent version: v4.1.2

Caught signal: SIGSEGV
Stack trace:
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x180f95  [0x7f10614a8f95]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x2f9603  [0x7f1061621603]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0x1d3eb8  [0x7f10614fbeb8]
  /usr/lib64/libtorrent-rasterbar.so.9 : ()+0xeb56f  [0x7f106141356f]
  /lib64/libpthread.so.0 : ()+0x7554  [0x7f106110f554]
  /lib64/libc.so.6 : clone()+0x3f  [0x7f105f652ccf]
Ошибка сегментирования (стек памяти сброшен на диск)

Whether somebody filed the bug to openSUSE?

@carlazz66

This comment has been minimized.

Show comment
Hide comment
@carlazz66

carlazz66 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 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

This comment has been minimized.

Show comment
Hide comment
@carlazz66

carlazz66 Sep 13, 2018

Exactly the same!

carlazz66 commented Sep 13, 2018

Exactly the same!

@olegantonyan

This comment has been minimized.

Show comment
Hide comment
@olegantonyan

olegantonyan Sep 13, 2018

A very dirty hack to reanimate qbittorrent until the issue is fixed. Pull these libraries

libboost_chrono.so.1.66.0
libboost_date_time.so.1.66.0
libboost_filesystem.so.1.66.0
libboost_iostreams.so.1.66.0
libboost_locale.so.1.66.0
libboost_system.so.1.66.0
libboost_thread.so.1.66.0
libtorrent-rasterbar.so.9 -> libtorrent-rasterbar.so.9.0.0
libtorrent-rasterbar.so.9.0.0

from Leap http://download.opensuse.org/distribution/openSUSE-current/repo/oss/x86_64/
Extract .so from their rpms, put in one folder and run LD_LIBRARY_PATH=/path/to/libs qbittorrent

olegantonyan commented Sep 13, 2018

A very dirty hack to reanimate qbittorrent until the issue is fixed. Pull these libraries

libboost_chrono.so.1.66.0
libboost_date_time.so.1.66.0
libboost_filesystem.so.1.66.0
libboost_iostreams.so.1.66.0
libboost_locale.so.1.66.0
libboost_system.so.1.66.0
libboost_thread.so.1.66.0
libtorrent-rasterbar.so.9 -> libtorrent-rasterbar.so.9.0.0
libtorrent-rasterbar.so.9.0.0

from Leap http://download.opensuse.org/distribution/openSUSE-current/repo/oss/x86_64/
Extract .so from their rpms, put in one folder and run LD_LIBRARY_PATH=/path/to/libs qbittorrent

@akontsevich

This comment has been minimized.

Show comment
Hide comment
@akontsevich

akontsevich 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?

akontsevich commented 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

This comment has been minimized.

Show comment
Hide comment
@Chocobo1

Chocobo1 Sep 14, 2018

Member

So qbittorrent works only with v1.66/1.67? Need to fix/update qbittorrent somehow?

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?

Member

Chocobo1 commented Sep 14, 2018

So qbittorrent works only with v1.66/1.67? Need to fix/update qbittorrent somehow?

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

This comment has been minimized.

Show comment
Hide comment
@zachberger

zachberger Sep 15, 2018

@olegantonyan would you be willing to zip those up and share them? It would make the work around much easier for others.

zachberger commented Sep 15, 2018

@olegantonyan would you be willing to zip those up and share them? It would make the work around much easier for others.

@olegantonyan

This comment has been minimized.

Show comment
Hide comment
@olegantonyan

olegantonyan commented Sep 15, 2018

@zachberger https://yadi.sk/d/LQRpxCAcfTxJDA 64bit libraries for opensuse

@carlazz66

This comment has been minimized.

Show comment
Hide comment
@carlazz66

carlazz66 Sep 15, 2018

@olegantonyan many thanks, it work well!

carlazz66 commented Sep 15, 2018

@olegantonyan many thanks, it work well!

@guoyunhe

This comment has been minimized.

Show comment
Hide comment
@guoyunhe

guoyunhe Sep 16, 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 Sep 16, 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

This comment has been minimized.

Show comment
Hide comment
@guoyunhe

guoyunhe commented Sep 16, 2018

I reported a bug to openSUSE Bugzilla https://bugzilla.opensuse.org/show_bug.cgi?id=1108567

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

Here's another bugreport worth mentioning: arvidn/libtorrent#3261
I suspect the issue is triggered by Boost 1.68.0 and isn't openSUSE-specific.

XRevan86 commented Sep 16, 2018

Here's another bugreport worth mentioning: arvidn/libtorrent#3261
I suspect the issue is triggered by Boost 1.68.0 and isn't openSUSE-specific.

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 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.

XRevan86 commented 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

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

@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.

Contributor

zeule commented 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

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

@zeule, no, it doesn't do that.

--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1,5 +1,9 @@
-set(CMAKE_CXX_STANDARD_REQUIRED True)
-set(CMAKE_CXX_STANDARD "11")
+if (CMAKE_CXX_STANDARD_COMPUTED_DEFAULT VERSION_GREATER_EQUAL "14")
+    set(CMAKE_CXX_STANDARD "14")
+else()
+    set(CMAKE_CXX_STANDARD "11")
+endif()
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
 include(MacroQbtCompilerSettings)
 qbt_set_compiler_options()

I am puzzled why qBittorrent with CMake builds with -std=gnu++11 by default (even when CMAKE_CXX_STANDARD is not set at all). The patch above works, but… why?

XRevan86 commented Sep 16, 2018

@zeule, no, it doesn't do that.

--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -1,5 +1,9 @@
-set(CMAKE_CXX_STANDARD_REQUIRED True)
-set(CMAKE_CXX_STANDARD "11")
+if (CMAKE_CXX_STANDARD_COMPUTED_DEFAULT VERSION_GREATER_EQUAL "14")
+    set(CMAKE_CXX_STANDARD "14")
+else()
+    set(CMAKE_CXX_STANDARD "11")
+endif()
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
 include(MacroQbtCompilerSettings)
 qbt_set_compiler_options()

I am puzzled why qBittorrent with CMake builds with -std=gnu++11 by default (even when CMAKE_CXX_STANDARD is not set at all). The patch above works, but… why?

zeule added a commit to zeule/qBittorrent that referenced this issue Sep 16, 2018

cmake: use C++14 when available
Libtorrent does the same and we have to follow since
its ABI depends on the C++ standard version.

Partially closes #9485.

@zeule zeule referenced a pull request that will close this issue Sep 16, 2018

Open

cmake: use C++14 when available #9509

@zeule

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

@XRevan86, thanks! But do you confirm that libtorrent contains -std=c++14 in its .pc file?

Contributor

zeule commented Sep 16, 2018

@XRevan86, thanks! But do you confirm that libtorrent contains -std=c++14 in its .pc file?

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

@zeule, no, it doesn't contain that.
libtorrent-rasterbar was actually built with autotools with no explicit -std.

XRevan86 commented Sep 16, 2018

@zeule, no, it doesn't contain that.
libtorrent-rasterbar was actually built with autotools with no explicit -std.

@zeule

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

Aha! That makes sense then. I can't find documentation entry for the CMAKE_CXX_STANDARD_COMPUTED_DEFAULT variable 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.

Contributor

zeule commented Sep 16, 2018

Aha! That makes sense then. I can't find documentation entry for the CMAKE_CXX_STANDARD_COMPUTED_DEFAULT variable 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

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

@zeule, I've got the impression that CMAKE_CXX_STANDARD is 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++11 in the build logs.
So what is happening exactly?

XRevan86 commented Sep 16, 2018

@zeule, I've got the impression that CMAKE_CXX_STANDARD is 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++11 in the build logs.
So what is happening exactly?

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

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.

@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).

XRevan86 commented Sep 16, 2018

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.

@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

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

Do you suggest then to use defaults if CMAKE_CXX_STANDARD_COMPUTED_DEFAULT value is greater or equal to 11?

Contributor

zeule commented Sep 16, 2018

Do you suggest then to use defaults if CMAKE_CXX_STANDARD_COMPUTED_DEFAULT value is greater or equal to 11?

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 16, 2018

@zeule, no, sorry, I didn't account for 98 > 14.

I noticed that Qt5 assumes -std=gnu++11 when building. But I cannot find any place where that translates to CMake.

cmake/cmake#17146 suggests that this could be a CMake bug.

XRevan86 commented Sep 16, 2018

@zeule, no, sorry, I didn't account for 98 > 14.

I noticed that Qt5 assumes -std=gnu++11 when building. But I cannot find any place where that translates to CMake.

cmake/cmake#17146 suggests that this could be a CMake bug.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 16, 2018

Contributor

@XRevan86 I assume that your gcc version has by default enabled c++14?

Contributor

sledgehammer999 commented Sep 16, 2018

@XRevan86 I assume that your gcc version has by default enabled c++14?

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 commented Sep 16, 2018

@sledgehammer999, yes, GCC 8.2.1.

@ngosang ngosang added OS: Linux Crash and removed OS: Linux labels Sep 16, 2018

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 16, 2018

Contributor

@XRevan86 can you try building with the configure script instead to see if it also works? From a glance, it should work better than the CMake variant.

Contributor

sledgehammer999 commented Sep 16, 2018

@XRevan86 can you try building with the configure script instead to see if it also works? From a glance, it should work better than the CMake variant.

@zeule

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

How could it work better when we have CONFIG += c++11 in src.pro?

Contributor

zeule commented Sep 16, 2018

How could it work better when we have CONFIG += c++11 in src.pro?

@zeule

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 16, 2018

Contributor

suggests that this could be a CMake bug.

Use C++17 in my fork without a problem.

Contributor

zeule commented Sep 16, 2018

suggests that this could be a CMake bug.

Use C++17 in my fork without a problem.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 16, 2018

Contributor

How could it work better when we have CONFIG += c++11 in src.pro?

My assumption is that QT/qmake requires it as a minimum. Otherwise I need to revise the autotools system too.

Contributor

sledgehammer999 commented Sep 16, 2018

How could it work better when we have CONFIG += c++11 in src.pro?

My assumption is that QT/qmake requires it as a minimum. Otherwise I need to revise the autotools system too.

@iiv3

This comment has been minimized.

Show comment
Hide comment
@iiv3

iiv3 Sep 17, 2018

May I propose to remove both

---a/src/CMakeLists.txt
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_STANDARD "11")

and

---a/src/src.pro
# C++11 support
CONFIG += c++11

The root of the problem is boost. It is the one that changes its API depending on the selected -std standard. It does not provide pkg-config on 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.pc provides some -std options, they could be only a guess.

If you want to do the right thing, then use this crash and recreate it as configure check.
You could even try a number of different known -std= variants until the test runs successfully.

iiv3 commented Sep 17, 2018

May I propose to remove both

---a/src/CMakeLists.txt
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_STANDARD "11")

and

---a/src/src.pro
# C++11 support
CONFIG += c++11

The root of the problem is boost. It is the one that changes its API depending on the selected -std standard. It does not provide pkg-config on 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.pc provides some -std options, they could be only a guess.

If you want to do the right thing, then use this crash and recreate it as configure check.
You could even try a number of different known -std= variants until the test runs successfully.

@XRevan86

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 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.

XRevan86 commented 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

This comment has been minimized.

Show comment
Hide comment
@zeule

zeule Sep 17, 2018

Contributor

Keep in mind that qBt code requires at least C++11.

Contributor

zeule commented Sep 17, 2018

Keep in mind that qBt code requires at least C++11.

@deelaka

This comment has been minimized.

Show comment
Hide comment
@deelaka

deelaka 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...

deelaka commented 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

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 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).

XRevan86 commented 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

This comment has been minimized.

Show comment
Hide comment
@akontsevich

akontsevich Sep 18, 2018

@XRevan86, yes it crashed for me after some new torrent file added to download.

akontsevich commented Sep 18, 2018

@XRevan86, yes it crashed for me after some new torrent file added to download.

@deelaka

This comment has been minimized.

Show comment
Hide comment
@deelaka

deelaka 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).

@XRevan86 Unfortunately I cannot confirm about the .fastresume file on my compiled version, there is however an empty session.lock file 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.2 on C++11 still produces a segmentation fault presumably from due to a ABI issue whereas @olegantonyan's solution presumably works which again loads boost-1.66 libs. But maybe I've made a mistake. Can anyone else confirm compiling with boost-1.66 still 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.

deelaka commented 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).

@XRevan86 Unfortunately I cannot confirm about the .fastresume file on my compiled version, there is however an empty session.lock file 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.2 on C++11 still produces a segmentation fault presumably from due to a ABI issue whereas @olegantonyan's solution presumably works which again loads boost-1.66 libs. But maybe I've made a mistake. Can anyone else confirm compiling with boost-1.66 still 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

This comment has been minimized.

Show comment
Hide comment
@XRevan86

XRevan86 Sep 18, 2018

Unfortunately I cannot confirm about the .fastresume file on my compiled version

@deelaka, from my observation, a faulty $HASH.fastresume file is what causes the start-up crash. If you have any $HASH.fastresume with no corresponding $HASH.torrent, I take it it can be safely removed (and I bet there is).

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.

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…

XRevan86 commented Sep 18, 2018

Unfortunately I cannot confirm about the .fastresume file on my compiled version

@deelaka, from my observation, a faulty $HASH.fastresume file is what causes the start-up crash. If you have any $HASH.fastresume with no corresponding $HASH.torrent, I take it it can be safely removed (and I bet there is).

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.

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

This comment has been minimized.

Show comment
Hide comment
@deelaka

deelaka 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.fastresume and $HASH.torrent files. 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.fastresume file 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.

deelaka commented 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.fastresume and $HASH.torrent files. 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.fastresume file 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

This comment has been minimized.

Show comment
Hide comment
@akontsevich

akontsevich Sep 19, 2018

Seems SUSE have fixed this with recent upgrade. Works fine!

akontsevich commented Sep 19, 2018

Seems SUSE have fixed this with recent upgrade. Works fine!

@nathanmkaya

This comment has been minimized.

Show comment
Hide comment
@nathanmkaya

nathanmkaya Sep 19, 2018

Seems SUSE have fixed this with recent upgrade. Works fine!

Yes they have

nathanmkaya commented Sep 19, 2018

Seems SUSE have fixed this with recent upgrade. Works fine!

Yes they have

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment