Re: [BUG] net/qbittorrent and net/deluge not working
On Sat, Sep 18, 2021 at 09:47:58PM +0200, Rafael Sadowski wrote: > On Sat Sep 18, 2021 at 09:55:11AM +0100, Stuart Henderson wrote: > > I am ok with this, but the following ports will need adjusting due to > > pkgspecs on particular boost versions: > > > > archivers/innoextract > > audio/py-tagpy,python3 > > devel/leatherman > > games/arx-libertatis > > games/freeorion > > games/valyriatear > > games/vegastrike/engine > > games/wesnoth > > graphics/hugin > > graphics/mapnik > > net/libtorrent-rasterbar > > sysutils/facter > > All ports were built properly. > > > > > I would suggest just removing the version checks (and bumping). > > > > I think the tight deps are often more trouble than they're worth, it's not > > like we support building from a mixture of old installed packages and newer > > ports tree anyway. They're useful if there are multiple versions of the same > > software in-tree and we need to depend on a particular version, or if > > there's a tight binding (like in irssi/dovecot where plugins must match the > > version exactly), or defensively to protect against updating a dependency to > > a version that is known to not be supported. But to ensure that a dependency > > is at a minimum version seems not worthwhile. > > > > Agree Reviewing these ports together and with how boost updates usually work, I'm also ok with removing the boost version checks. They add complexity without being helpful in any of the cases. > [...]
Re: [BUG] net/qbittorrent and net/deluge not working
On 9/18/2021 4:37 AM, Rafael Sadowski wrote:
On Thu Sep 16, 2021 at 08:44:00AM +0100, Stuart Henderson wrote:
On 2021/09/15 23:15, Brad Smith wrote:
Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0 initially)
and it no longer was crashing on me. I started up qBittorrent and downloaded
a few well seeded torrents.
Unless we understand the mechanism for the failure and are sure it's a
libtorrent-rasterbar problem rather than a boost one, a backout would
seem a better idea. We are locking soon and can't add -O1 to ~170 ports
if the problem is in boost and an unknown number of others might be
affected.
Runtime tests on boost ports are problematic. Ports only using the
"header only library" as a BUILD_DEPENDS do *not* get updated for a
boost version bump so testers could easily be using the old code still.
I think Stuart is right. 7.0 is coming and we should play it safe.
OK?
OK.
Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.116
diff -u -p -u -p -r1.116 Makefile
--- Makefile3 Sep 2021 23:23:30 - 1.116
+++ Makefile18 Sep 2021 06:42:26 -
@@ -1,11 +1,12 @@
-# $OpenBSD: Makefile,v 1.116 2021/09/03 23:23:30 sthen Exp $
+# $OpenBSD: Makefile,v 1.115 2021/07/16 17:55:10 sthen Exp $
ONLY_FOR_ARCHS-md = aarch64 amd64 arm i386 mips64 mips64el powerpc powerpc64 riscv64
COMMENT-main= free peer-reviewed portable C++ source libraries
COMMENT-md= machine-dependent libraries for boost
-VERSION= 1.77.0
+VERSION= 1.76.0
+EPOCH =0
DISTNAME= boost_${VERSION:S/./_/g}
PKGNAME-main= boost-${VERSION}
PKGNAME-md= boost-md-${VERSION}
@@ -14,7 +15,7 @@ MASTER_SITES= https://boostorg.jfrog.io/
EXTRACT_SUFX= .tar.bz2
FIX_EXTRACT_PERMISSIONS = Yes
-SO_VERSION= 16.0
+SO_VERSION=17.0
BOOST_LIBS= boost_atomic-mt \
boost_chrono-mt boost_chrono \
boost_container-mt boost_container \
@@ -107,8 +108,8 @@ BJAM_CONFIG=-sICU_PATH=${LOCALBASE} \
-j${MAKE_JOBS} \
--layout=tagged-1.66 \
pch=off \
- cflags='${CFLAGS}' \
- cxxflags='${CXXFLAGS}' \
+ cflags='${CFLAGS} -pthread' \
+ cxxflags='${CXXFLAGS} -pthread' \
variant=release \
link=static,shared \
threading=single,multi \
Index: distinfo
===
RCS file: /cvs/ports/devel/boost/distinfo,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 distinfo
--- distinfo3 Sep 2021 23:23:30 - 1.16
+++ distinfo18 Sep 2021 06:42:26 -
@@ -1,2 +1,2 @@
-SHA256 (boost_1_77_0.tar.bz2) = /J+F/AMOIzFCkIJBr3qEbmBjCqc4jeml+vsfOiaECFQ=
-SIZE (boost_1_77_0.tar.bz2) = 110361537
+SHA256 (boost_1_76_0.tar.bz2) = 8Dl7pumCxEUPJ78yoqgykqugNbgnpWI6FGNupYMxjEE=
+SIZE (boost_1_76_0.tar.bz2) = 110073117
Index: patches/patch-Jamroot
===
RCS file: /cvs/ports/devel/boost/patches/patch-Jamroot,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 patch-Jamroot
--- patches/patch-Jamroot 3 Sep 2021 23:23:31 - 1.12
+++ patches/patch-Jamroot 18 Sep 2021 06:42:26 -
@@ -1,11 +1,11 @@
-$OpenBSD: patch-Jamroot,v 1.12 2021/09/03 23:23:31 sthen Exp $
+$OpenBSD: patch-Jamroot,v 1.11 2021/06/22 04:20:13 rsadowski Exp $
Index: Jamroot
--- Jamroot.orig
+++ Jamroot
@@ -146,11 +146,12 @@ import tools/boost\_install/boost-install ;
path-constant BOOST_ROOT : . ;
- constant BOOST_VERSION : 1.77.0 ;
+ constant BOOST_VERSION : 1.76.0 ;
constant BOOST_JAMROOT_MODULE : $(__name__) ;
+constant SO_VERSION : ${SO_VERSION} ;
Index: patches/patch-boost_asio_ssl_impl_context_ipp
===
RCS file: patches/patch-boost_asio_ssl_impl_context_ipp
diff -N patches/patch-boost_asio_ssl_impl_context_ipp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-boost_asio_ssl_impl_context_ipp 18 Sep 2021 06:42:26
-
@@ -0,0 +1,77 @@
+$OpenBSD: patch-boost_asio_ssl_impl_context_ipp,v 1.5 2021/07/16 17:55:10
sthen Exp $
+
+Fix compatibility with recent LibreSSL when OPENSSL_NO_SSL_INTERN is defined.
+
+Index: boost/asio/ssl/impl/context.ipp
+--- boost/asio/ssl/impl/context.ipp.orig
boost/asio/ssl/impl/context.ipp
+@@ -398,7 +398,8 @@ context::~context()
+ if (handle_)
+ {
+ #if ((OPENSSL_VERSION_NUMBER >= 0x1010L) \
+- && !defined(LIBRESSL_VERSION_NUMBER)) \
++ && (!defined(LIBRESSL_VERSION_NUMBER) \
++|| LIBRESSL_VERSION_NUMBER >= 0x207fL)) \
+ || defined(BOOST_ASIO_USE_WOLFSSL)
+ void* cb_userdata = ::SSL_CTX_get_default_passwd_cb_userdata(handle_);
+ #else // (OPENSSL_VERSION_NUMBER >= 0x1010L)
+@@ -411,7 +412,8 @@ context::~context()
+
Re: [BUG] net/qbittorrent and net/deluge not working
On Sat Sep 18, 2021 at 09:55:11AM +0100, Stuart Henderson wrote:
> I am ok with this, but the following ports will need adjusting due to
> pkgspecs on particular boost versions:
>
> archivers/innoextract
> audio/py-tagpy,python3
> devel/leatherman
> games/arx-libertatis
> games/freeorion
> games/valyriatear
> games/vegastrike/engine
> games/wesnoth
> graphics/hugin
> graphics/mapnik
> net/libtorrent-rasterbar
> sysutils/facter
All ports were built properly.
>
> I would suggest just removing the version checks (and bumping).
>
> I think the tight deps are often more trouble than they're worth, it's not
> like we support building from a mixture of old installed packages and newer
> ports tree anyway. They're useful if there are multiple versions of the same
> software in-tree and we need to depend on a particular version, or if
> there's a tight binding (like in irssi/dovecot where plugins must match the
> version exactly), or defensively to protect against updating a dependency to
> a version that is known to not be supported. But to ensure that a dependency
> is at a minimum version seems not worthwhile.
>
Agree
Index: archivers/innoextract/Makefile
===
RCS file: /cvs/ports/archivers/innoextract/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- archivers/innoextract/Makefile 24 Aug 2021 20:32:52 - 1.18
+++ archivers/innoextract/Makefile 18 Sep 2021 19:05:18 -
@@ -3,7 +3,7 @@
COMMENT= unpack Inno Setup installers
DISTNAME= innoextract-1.9
-REVISION= 1
+REVISION= 2
CATEGORIES=archivers
HOMEPAGE= https://constexpr.org/innoextract/
MAINTAINER=Thomas Frohwein
@@ -23,7 +23,7 @@ COMPILER= base-clang ports-gcc
LIB_DEPENDS= archivers/xz \
converters/libiconv \
- devel/boost>=1.70.0
+ devel/boost
RUN_DEPENDS= archivers/unrar
Index: audio/py-tagpy/Makefile
===
RCS file: /cvs/ports/audio/py-tagpy/Makefile,v
retrieving revision 1.33
diff -u -p -r1.33 Makefile
--- audio/py-tagpy/Makefile 4 Jan 2021 14:06:27 - 1.33
+++ audio/py-tagpy/Makefile 18 Sep 2021 19:05:19 -
@@ -5,7 +5,7 @@ COMMENT=Python bindings to TagLib audi
MODPY_EGG_VERSION =2013.1
DISTNAME = tagpy-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 14
+REVISION = 15
CATEGORIES = audio devel
@@ -29,7 +29,7 @@ FLAVOR = python3
LIB_DEPENDS = lang/python/${MODPY_VERSION} \
audio/taglib \
- devel/boost>=1.67.0
+ devel/boost
CONFIGURE_ARGS += --boost-compiler=gcc42 \
--boost-lib-dir=${LOCALBASE}/lib \
Index: devel/boost/Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.116
diff -u -p -r1.116 Makefile
--- devel/boost/Makefile3 Sep 2021 23:23:30 - 1.116
+++ devel/boost/Makefile18 Sep 2021 19:05:23 -
@@ -1,11 +1,12 @@
-# $OpenBSD: Makefile,v 1.116 2021/09/03 23:23:30 sthen Exp $
+# $OpenBSD: Makefile,v 1.115 2021/07/16 17:55:10 sthen Exp $
ONLY_FOR_ARCHS-md = aarch64 amd64 arm i386 mips64 mips64el powerpc powerpc64
riscv64
COMMENT-main= free peer-reviewed portable C++ source libraries
COMMENT-md=machine-dependent libraries for boost
-VERSION= 1.77.0
+VERSION= 1.76.0
+EPOCH =0
DISTNAME= boost_${VERSION:S/./_/g}
PKGNAME-main= boost-${VERSION}
PKGNAME-md=boost-md-${VERSION}
@@ -14,7 +15,7 @@ MASTER_SITES= https://boostorg.jfrog.io/
EXTRACT_SUFX= .tar.bz2
FIX_EXTRACT_PERMISSIONS = Yes
-SO_VERSION=16.0
+SO_VERSION=17.0
BOOST_LIBS=boost_atomic-mt \
boost_chrono-mt boost_chrono \
boost_container-mt boost_container \
@@ -107,8 +108,8 @@ BJAM_CONFIG=-sICU_PATH=${LOCALBASE} \
-j${MAKE_JOBS} \
--layout=tagged-1.66 \
pch=off \
- cflags='${CFLAGS}' \
- cxxflags='${CXXFLAGS}' \
+ cflags='${CFLAGS} -pthread' \
+ cxxflags='${CXXFLAGS} -pthread' \
variant=release \
link=static,shared \
threading=single,multi \
Index: devel/boost/distinfo
===
RCS file: /cvs/ports/devel/boost/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- devel/boost/distinfo3 Sep 2021 23:23:30 - 1.16
+++ devel/boost/distinfo18 Sep 2021 19:05:23 -
@@ -1,2 +1,2 @@
-SHA256 (boost_1_77_0.tar.bz2) = /J+F/AMOIzFCkIJBr3qEbmBjCqc4jeml+vsfOiaECFQ=
-SIZE (boost_1_77_0.tar.bz2) = 110361537
+SHA256 (boost_1_76_0.tar.bz2)
Re: [BUG] net/qbittorrent and net/deluge not working
I am ok with this, but the following ports will need adjusting due to
pkgspecs on particular boost versions:
archivers/innoextract
audio/py-tagpy,python3
devel/leatherman
games/arx-libertatis
games/freeorion
games/valyriatear
games/vegastrike/engine
games/wesnoth
graphics/hugin
graphics/mapnik
net/libtorrent-rasterbar
sysutils/facter
I would suggest just removing the version checks (and bumping).
I think the tight deps are often more trouble than they're worth, it's not
like we support building from a mixture of old installed packages and newer
ports tree anyway. They're useful if there are multiple versions of the
same software in-tree and we need to depend on a particular version, or if
there's a tight binding (like in irssi/dovecot where plugins must match the
version exactly), or defensively to protect against updating a dependency
to a version that is known to not be supported. But to ensure that a
dependency is at a minimum version seems not worthwhile.
--
Sent from a phone, apologies for poor formatting.
On 18 September 2021 07:44:46 Rafael Sadowski wrote:
On Thu Sep 16, 2021 at 08:44:00AM +0100, Stuart Henderson wrote:
On 2021/09/15 23:15, Brad Smith wrote:
> Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0
initially)
> and it no longer was crashing on me. I started up qBittorrent and downloaded
> a few well seeded torrents.
Unless we understand the mechanism for the failure and are sure it's a
libtorrent-rasterbar problem rather than a boost one, a backout would
seem a better idea. We are locking soon and can't add -O1 to ~170 ports
if the problem is in boost and an unknown number of others might be
affected.
Runtime tests on boost ports are problematic. Ports only using the
"header only library" as a BUILD_DEPENDS do *not* get updated for a
boost version bump so testers could easily be using the old code still.
I think Stuart is right. 7.0 is coming and we should play it safe.
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.116
diff -u -p -u -p -r1.116 Makefile
--- Makefile3 Sep 2021 23:23:30 - 1.116
+++ Makefile18 Sep 2021 06:42:26 -
@@ -1,11 +1,12 @@
-# $OpenBSD: Makefile,v 1.116 2021/09/03 23:23:30 sthen Exp $
+# $OpenBSD: Makefile,v 1.115 2021/07/16 17:55:10 sthen Exp $
ONLY_FOR_ARCHS-md = aarch64 amd64 arm i386 mips64 mips64el powerpc
powerpc64 riscv64
COMMENT-main= free peer-reviewed portable C++ source libraries
COMMENT-md= machine-dependent libraries for boost
-VERSION= 1.77.0
+VERSION= 1.76.0
+EPOCH =0
DISTNAME= boost_${VERSION:S/./_/g}
PKGNAME-main= boost-${VERSION}
PKGNAME-md= boost-md-${VERSION}
@@ -14,7 +15,7 @@ MASTER_SITES= https://boostorg.jfrog.io/
EXTRACT_SUFX= .tar.bz2
FIX_EXTRACT_PERMISSIONS = Yes
-SO_VERSION=16.0
+SO_VERSION=17.0
BOOST_LIBS= boost_atomic-mt \
boost_chrono-mt boost_chrono \
boost_container-mt boost_container \
@@ -107,8 +108,8 @@ BJAM_CONFIG=-sICU_PATH=${LOCALBASE} \
-j${MAKE_JOBS} \
--layout=tagged-1.66 \
pch=off \
- cflags='${CFLAGS}' \
- cxxflags='${CXXFLAGS}' \
+ cflags='${CFLAGS} -pthread' \
+ cxxflags='${CXXFLAGS} -pthread' \
variant=release \
link=static,shared \
threading=single,multi \
Index: distinfo
===
RCS file: /cvs/ports/devel/boost/distinfo,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 distinfo
--- distinfo3 Sep 2021 23:23:30 - 1.16
+++ distinfo18 Sep 2021 06:42:26 -
@@ -1,2 +1,2 @@
-SHA256 (boost_1_77_0.tar.bz2) = /J+F/AMOIzFCkIJBr3qEbmBjCqc4jeml+vsfOiaECFQ=
-SIZE (boost_1_77_0.tar.bz2) = 110361537
+SHA256 (boost_1_76_0.tar.bz2) = 8Dl7pumCxEUPJ78yoqgykqugNbgnpWI6FGNupYMxjEE=
+SIZE (boost_1_76_0.tar.bz2) = 110073117
Index: patches/patch-Jamroot
===
RCS file: /cvs/ports/devel/boost/patches/patch-Jamroot,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 patch-Jamroot
--- patches/patch-Jamroot 3 Sep 2021 23:23:31 - 1.12
+++ patches/patch-Jamroot 18 Sep 2021 06:42:26 -
@@ -1,11 +1,11 @@
-$OpenBSD: patch-Jamroot,v 1.12 2021/09/03 23:23:31 sthen Exp $
+$OpenBSD: patch-Jamroot,v 1.11 2021/06/22 04:20:13 rsadowski Exp $
Index: Jamroot
--- Jamroot.orig
+++ Jamroot
@@ -146,11 +146,12 @@ import tools/boost\_install/boost-install ;
path-constant BOOST_ROOT : . ;
- constant BOOST_VERSION : 1.77.0 ;
+ constant BOOST_VERSION : 1.76.0 ;
constant BOOST_JAMROOT_MODULE : $(__name__) ;
+constant SO_VERSION : ${SO_VERSION} ;
Index: patches/patch-boost_asio_ssl_impl_context_ipp
===
RCS
Re: [BUG] net/qbittorrent and net/deluge not working
On Thu Sep 16, 2021 at 08:44:00AM +0100, Stuart Henderson wrote:
> On 2021/09/15 23:15, Brad Smith wrote:
> > Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0
> > initially)
> > and it no longer was crashing on me. I started up qBittorrent and downloaded
> > a few well seeded torrents.
>
> Unless we understand the mechanism for the failure and are sure it's a
> libtorrent-rasterbar problem rather than a boost one, a backout would
> seem a better idea. We are locking soon and can't add -O1 to ~170 ports
> if the problem is in boost and an unknown number of others might be
> affected.
>
> Runtime tests on boost ports are problematic. Ports only using the
> "header only library" as a BUILD_DEPENDS do *not* get updated for a
> boost version bump so testers could easily be using the old code still.
>
I think Stuart is right. 7.0 is coming and we should play it safe.
OK?
Index: Makefile
===
RCS file: /cvs/ports/devel/boost/Makefile,v
retrieving revision 1.116
diff -u -p -u -p -r1.116 Makefile
--- Makefile3 Sep 2021 23:23:30 - 1.116
+++ Makefile18 Sep 2021 06:42:26 -
@@ -1,11 +1,12 @@
-# $OpenBSD: Makefile,v 1.116 2021/09/03 23:23:30 sthen Exp $
+# $OpenBSD: Makefile,v 1.115 2021/07/16 17:55:10 sthen Exp $
ONLY_FOR_ARCHS-md = aarch64 amd64 arm i386 mips64 mips64el powerpc powerpc64
riscv64
COMMENT-main= free peer-reviewed portable C++ source libraries
COMMENT-md=machine-dependent libraries for boost
-VERSION= 1.77.0
+VERSION= 1.76.0
+EPOCH =0
DISTNAME= boost_${VERSION:S/./_/g}
PKGNAME-main= boost-${VERSION}
PKGNAME-md=boost-md-${VERSION}
@@ -14,7 +15,7 @@ MASTER_SITES= https://boostorg.jfrog.io/
EXTRACT_SUFX= .tar.bz2
FIX_EXTRACT_PERMISSIONS = Yes
-SO_VERSION=16.0
+SO_VERSION=17.0
BOOST_LIBS=boost_atomic-mt \
boost_chrono-mt boost_chrono \
boost_container-mt boost_container \
@@ -107,8 +108,8 @@ BJAM_CONFIG=-sICU_PATH=${LOCALBASE} \
-j${MAKE_JOBS} \
--layout=tagged-1.66 \
pch=off \
- cflags='${CFLAGS}' \
- cxxflags='${CXXFLAGS}' \
+ cflags='${CFLAGS} -pthread' \
+ cxxflags='${CXXFLAGS} -pthread' \
variant=release \
link=static,shared \
threading=single,multi \
Index: distinfo
===
RCS file: /cvs/ports/devel/boost/distinfo,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 distinfo
--- distinfo3 Sep 2021 23:23:30 - 1.16
+++ distinfo18 Sep 2021 06:42:26 -
@@ -1,2 +1,2 @@
-SHA256 (boost_1_77_0.tar.bz2) = /J+F/AMOIzFCkIJBr3qEbmBjCqc4jeml+vsfOiaECFQ=
-SIZE (boost_1_77_0.tar.bz2) = 110361537
+SHA256 (boost_1_76_0.tar.bz2) = 8Dl7pumCxEUPJ78yoqgykqugNbgnpWI6FGNupYMxjEE=
+SIZE (boost_1_76_0.tar.bz2) = 110073117
Index: patches/patch-Jamroot
===
RCS file: /cvs/ports/devel/boost/patches/patch-Jamroot,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 patch-Jamroot
--- patches/patch-Jamroot 3 Sep 2021 23:23:31 - 1.12
+++ patches/patch-Jamroot 18 Sep 2021 06:42:26 -
@@ -1,11 +1,11 @@
-$OpenBSD: patch-Jamroot,v 1.12 2021/09/03 23:23:31 sthen Exp $
+$OpenBSD: patch-Jamroot,v 1.11 2021/06/22 04:20:13 rsadowski Exp $
Index: Jamroot
--- Jamroot.orig
+++ Jamroot
@@ -146,11 +146,12 @@ import tools/boost\_install/boost-install ;
path-constant BOOST_ROOT : . ;
- constant BOOST_VERSION : 1.77.0 ;
+ constant BOOST_VERSION : 1.76.0 ;
constant BOOST_JAMROOT_MODULE : $(__name__) ;
+constant SO_VERSION : ${SO_VERSION} ;
Index: patches/patch-boost_asio_ssl_impl_context_ipp
===
RCS file: patches/patch-boost_asio_ssl_impl_context_ipp
diff -N patches/patch-boost_asio_ssl_impl_context_ipp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-boost_asio_ssl_impl_context_ipp 18 Sep 2021 06:42:26
-
@@ -0,0 +1,77 @@
+$OpenBSD: patch-boost_asio_ssl_impl_context_ipp,v 1.5 2021/07/16 17:55:10
sthen Exp $
+
+Fix compatibility with recent LibreSSL when OPENSSL_NO_SSL_INTERN is defined.
+
+Index: boost/asio/ssl/impl/context.ipp
+--- boost/asio/ssl/impl/context.ipp.orig
boost/asio/ssl/impl/context.ipp
+@@ -398,7 +398,8 @@ context::~context()
+ if (handle_)
+ {
+ #if ((OPENSSL_VERSION_NUMBER >= 0x1010L) \
+- && !defined(LIBRESSL_VERSION_NUMBER)) \
++ && (!defined(LIBRESSL_VERSION_NUMBER) \
++|| LIBRESSL_VERSION_NUMBER >= 0x207fL)) \
+ || defined(BOOST_ASIO_USE_WOLFSSL)
+ void* cb_userdata = ::SSL_CTX_get_default_passwd_cb_userdata(handle_);
+ #else // (OPENSSL_VERSION_NUMBER >= 0x1010L)
+@@ -411,7 +412,8 @@ context::~context()
+ cb_userdata);
+
Re: [BUG] net/qbittorrent and net/deluge not working
On 2021/09/15 23:15, Brad Smith wrote: > Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0 > initially) > and it no longer was crashing on me. I started up qBittorrent and downloaded > a few well seeded torrents. Unless we understand the mechanism for the failure and are sure it's a libtorrent-rasterbar problem rather than a boost one, a backout would seem a better idea. We are locking soon and can't add -O1 to ~170 ports if the problem is in boost and an unknown number of others might be affected. Runtime tests on boost ports are problematic. Ports only using the "header only library" as a BUILD_DEPENDS do *not* get updated for a boost version bump so testers could easily be using the old code still.
Re: [BUG] net/qbittorrent and net/deluge not working
On Wed, Sep 15, 2021 at 08:14:03AM +0200, Rafael Sadowski wrote:
> On Tue Sep 14, 2021 at 12:58:52PM +0200, Theo Buehler wrote:
> > On Tue, Sep 14, 2021 at 10:19:41AM +0100, Stuart Henderson wrote:
> > > Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405
> >
> > I tried updating libtorrent-rasterbar to 1.2.14 and bumping
> > TORRENT_{READ,WRITE}_HANDLER_MAX_SIZE by 16 bytes to match what was
> > discussed in that thread for libtorrent 2.0.x.I still get the same
>
> Did the same without luck. I also tested libtorrent-rasterbar with
> boost_system instead of boost_system-mt.
>
> > abort (also the bogus pointer (double free?) seen in the backtrace
> > suggests that the problem is a different one.
> >
> > >
> > > Users of other software that uses boost: please test snapshots ASAP and
> > > report back if there are recent problems.
> > >
> > > --
> > > Sent from a phone, apologies for poor formatting.
> > >
> > > On 14 September 2021 03:24:53 "Elias M. Mariani"
> > > wrote:
> > > > Thanks for the links Theo, I didn't know about those mirrors with the
> > > > previous builds.
> > > > Yep, the problem seems to lie with the boost update from 1.76 to 1.77.
> > > > Using 1.76 works OK.
> > > >
> > > > On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler
> > > > wrote:
> > > > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote:
> > > > > I should add some more info:
> > > > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or
> > > > > so
> > > > > ago. I just tested deluge because it uses the same libraries.
> > > > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The
> > > > > same
> > > > > applies for deluge.
> > > > > I tested both in a vanilla -current machine just to be sure that
> > > > > nothing
> > > > > was on the way...
> > > >
> > > > There was a similar report on bugs (Sep 9):
> > > > https://marc.info/?l=openbsd-bugs=163120864431955=2
> > > >
> > > > The timeframe of "one week or so" and the trace make it likely that it
> > > > is the boost 1.77 update.
> > > >
> > > > This is the last snapshot with boost-1.76p0:
> > > > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/
> > > > If that works and the next snapshot with boost-1.77 is broken...
> > > > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
> > >
Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0 initially)
and it no longer was crashing on me. I started up qBittorrent and downloaded
a few well seeded torrents.
Index: Makefile
===
RCS file: /home/cvs/ports/net/libtorrent-rasterbar/Makefile,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 Makefile
--- Makefile22 May 2021 21:47:28 - 1.16
+++ Makefile16 Sep 2021 03:03:23 -
@@ -4,6 +4,7 @@ COMMENT = C++ library implementing a Bi
MODPY_EGG_VERSION =1.2.13
DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
+REVISION = 0
SHARED_LIBS += torrent-rasterbar 4.0 # 10.0.0
@@ -25,6 +26,9 @@ BUILD_DEPENDS = devel/libtool
LIB_DEPENDS = converters/libiconv \
devel/boost>=1.67.0
+
+# XXX Boost
+CXXFLAGS+= -O1
# boost
COMPILER = base-clang ports-gcc
Re: [BUG] net/qbittorrent and net/deluge not working
On Wed Sep 15, 2021 at 11:15:59PM -0400, Brad Smith wrote:
> On Wed, Sep 15, 2021 at 08:14:03AM +0200, Rafael Sadowski wrote:
> > On Tue Sep 14, 2021 at 12:58:52PM +0200, Theo Buehler wrote:
> > > On Tue, Sep 14, 2021 at 10:19:41AM +0100, Stuart Henderson wrote:
> > > > Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405
> > >
> > > I tried updating libtorrent-rasterbar to 1.2.14 and bumping
> > > TORRENT_{READ,WRITE}_HANDLER_MAX_SIZE by 16 bytes to match what was
> > > discussed in that thread for libtorrent 2.0.x.I still get the same
> >
> > Did the same without luck. I also tested libtorrent-rasterbar with
> > boost_system instead of boost_system-mt.
> >
> > > abort (also the bogus pointer (double free?) seen in the backtrace
> > > suggests that the problem is a different one.
> > >
> > > >
> > > > Users of other software that uses boost: please test snapshots ASAP and
> > > > report back if there are recent problems.
> > > >
> > > > --
> > > > Sent from a phone, apologies for poor formatting.
> > > >
> > > > On 14 September 2021 03:24:53 "Elias M. Mariani"
> > > >
> > > > wrote:
> > > > > Thanks for the links Theo, I didn't know about those mirrors with the
> > > > > previous builds.
> > > > > Yep, the problem seems to lie with the boost update from 1.76 to 1.77.
> > > > > Using 1.76 works OK.
> > > > >
> > > > > On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler
> > > > > wrote:
> > > > > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote:
> > > > > > I should add some more info:
> > > > > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week
> > > > > > or so
> > > > > > ago. I just tested deluge because it uses the same libraries.
> > > > > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The
> > > > > > same
> > > > > > applies for deluge.
> > > > > > I tested both in a vanilla -current machine just to be sure that
> > > > > > nothing
> > > > > > was on the way...
> > > > >
> > > > > There was a similar report on bugs (Sep 9):
> > > > > https://marc.info/?l=openbsd-bugs=163120864431955=2
> > > > >
> > > > > The timeframe of "one week or so" and the trace make it likely that it
> > > > > is the boost 1.77 update.
> > > > >
> > > > > This is the last snapshot with boost-1.76p0:
> > > > > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/
> > > > > If that works and the next snapshot with boost-1.77 is broken...
> > > > > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
> > > >
>
> Interesting. I found rebuilding libtorrent-rasterbar with -O1 (or -O0
> initially)
> and it no longer was crashing on me. I started up qBittorrent and downloaded
> a few well seeded torrents.
>
I can confirm that. OK?
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/net/libtorrent-rasterbar/Makefile,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 Makefile
> --- Makefile 22 May 2021 21:47:28 - 1.16
> +++ Makefile 16 Sep 2021 03:03:23 -
> @@ -4,6 +4,7 @@ COMMENT = C++ library implementing a Bi
>
> MODPY_EGG_VERSION = 1.2.13
> DISTNAME = libtorrent-rasterbar-${MODPY_EGG_VERSION}
> +REVISION = 0
>
> SHARED_LIBS += torrent-rasterbar 4.0 # 10.0.0
>
> @@ -25,6 +26,9 @@ BUILD_DEPENDS = devel/libtool
>
> LIB_DEPENDS =converters/libiconv \
> devel/boost>=1.67.0
> +
> +# XXX Boost
> +CXXFLAGS+= -O1
>
> # boost
> COMPILER = base-clang ports-gcc
>
Re: [BUG] net/qbittorrent and net/deluge not working
On Tue Sep 14, 2021 at 12:58:52PM +0200, Theo Buehler wrote:
> On Tue, Sep 14, 2021 at 10:19:41AM +0100, Stuart Henderson wrote:
> > Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405
>
> I tried updating libtorrent-rasterbar to 1.2.14 and bumping
> TORRENT_{READ,WRITE}_HANDLER_MAX_SIZE by 16 bytes to match what was
> discussed in that thread for libtorrent 2.0.x.I still get the same
Did the same without luck. I also tested libtorrent-rasterbar with
boost_system instead of boost_system-mt.
> abort (also the bogus pointer (double free?) seen in the backtrace
> suggests that the problem is a different one.
>
> >
> > Users of other software that uses boost: please test snapshots ASAP and
> > report back if there are recent problems.
> >
> > --
> > Sent from a phone, apologies for poor formatting.
> >
> > On 14 September 2021 03:24:53 "Elias M. Mariani"
> > wrote:
> > > Thanks for the links Theo, I didn't know about those mirrors with the
> > > previous builds.
> > > Yep, the problem seems to lie with the boost update from 1.76 to 1.77.
> > > Using 1.76 works OK.
> > >
> > > On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote:
> > > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote:
> > > > I should add some more info:
> > > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so
> > > > ago. I just tested deluge because it uses the same libraries.
> > > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same
> > > > applies for deluge.
> > > > I tested both in a vanilla -current machine just to be sure that nothing
> > > > was on the way...
> > >
> > > There was a similar report on bugs (Sep 9):
> > > https://marc.info/?l=openbsd-bugs=163120864431955=2
> > >
> > > The timeframe of "one week or so" and the trace make it likely that it
> > > is the boost 1.77 update.
> > >
> > > This is the last snapshot with boost-1.76p0:
> > > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/
> > > If that works and the next snapshot with boost-1.77 is broken...
> > > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
> >
Re: [BUG] net/qbittorrent and net/deluge not working
On Tue, Sep 14, 2021 at 10:19:41AM +0100, Stuart Henderson wrote:
> Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405
I tried updating libtorrent-rasterbar to 1.2.14 and bumping
TORRENT_{READ,WRITE}_HANDLER_MAX_SIZE by 16 bytes to match what was
discussed in that thread for libtorrent 2.0.x. I still get the same
abort (also the bogus pointer (double free?) seen in the backtrace
suggests that the problem is a different one.
>
> Users of other software that uses boost: please test snapshots ASAP and
> report back if there are recent problems.
>
> --
> Sent from a phone, apologies for poor formatting.
>
> On 14 September 2021 03:24:53 "Elias M. Mariani"
> wrote:
> > Thanks for the links Theo, I didn't know about those mirrors with the
> > previous builds.
> > Yep, the problem seems to lie with the boost update from 1.76 to 1.77.
> > Using 1.76 works OK.
> >
> > On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote:
> > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote:
> > > I should add some more info:
> > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so
> > > ago. I just tested deluge because it uses the same libraries.
> > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same
> > > applies for deluge.
> > > I tested both in a vanilla -current machine just to be sure that nothing
> > > was on the way...
> >
> > There was a similar report on bugs (Sep 9):
> > https://marc.info/?l=openbsd-bugs=163120864431955=2
> >
> > The timeframe of "one week or so" and the trace make it likely that it
> > is the boost 1.77 update.
> >
> > This is the last snapshot with boost-1.76p0:
> > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/
> > If that works and the next snapshot with boost-1.77 is broken...
> > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
>
Re: [BUG] net/qbittorrent and net/deluge not working
Maybe relevant: https://github.com/arvidn/libtorrent/issues/6405 Users of other software that uses boost: please test snapshots ASAP and report back if there are recent problems. -- Sent from a phone, apologies for poor formatting. On 14 September 2021 03:24:53 "Elias M. Mariani" wrote: Thanks for the links Theo, I didn't know about those mirrors with the previous builds. Yep, the problem seems to lie with the boost update from 1.76 to 1.77. Using 1.76 works OK. On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote: On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote: I should add some more info: - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so ago. I just tested deluge because it uses the same libraries. - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same applies for deluge. I tested both in a vanilla -current machine just to be sure that nothing was on the way... There was a similar report on bugs (Sep 9): https://marc.info/?l=openbsd-bugs=163120864431955=2 The timeframe of "one week or so" and the trace make it likely that it is the boost 1.77 update. This is the last snapshot with boost-1.76p0: https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/ If that works and the next snapshot with boost-1.77 is broken... https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
Re: [BUG] net/qbittorrent and net/deluge not working
Thanks for the links Theo, I didn't know about those mirrors with the previous builds. Yep, the problem seems to lie with the boost update from 1.76 to 1.77. Using 1.76 works OK. On Mon, Sep 13, 2021 at 6:28 PM Theo Buehler wrote: > On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote: > > I should add some more info: > > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so > > ago. I just tested deluge because it uses the same libraries. > > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same > > applies for deluge. > > I tested both in a vanilla -current machine just to be sure that nothing > > was on the way... > > There was a similar report on bugs (Sep 9): > https://marc.info/?l=openbsd-bugs=163120864431955=2 > > The timeframe of "one week or so" and the trace make it likely that it > is the boost 1.77 update. > > This is the last snapshot with boost-1.76p0: > https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/ > If that works and the next snapshot with boost-1.77 is broken... > https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/ >
Re: [BUG] net/qbittorrent and net/deluge not working
On Mon, Sep 13, 2021 at 05:55:51PM -0300, Elias M. Mariani wrote: > I should add some more info: > - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so > ago. I just tested deluge because it uses the same libraries. > - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same > applies for deluge. > I tested both in a vanilla -current machine just to be sure that nothing > was on the way... There was a similar report on bugs (Sep 9): https://marc.info/?l=openbsd-bugs=163120864431955=2 The timeframe of "one week or so" and the trace make it likely that it is the boost 1.77 update. This is the last snapshot with boost-1.76p0: https://ftp.hostserver.de/archive/2021-09-05-0105/snapshots/ If that works and the next snapshot with boost-1.77 is broken... https://ftp.hostserver.de/archive/2021-09-06-0105/snapshots/
Re: [BUG] net/qbittorrent and net/deluge not working
I should add some more info: - I tested this on amd64, qbittorrent 4.3.8 was working OK a week or so ago. I just tested deluge because it uses the same libraries. - Reproduce: pkg_add qbittorrent on -current, run qbittorrent. The same applies for deluge. I tested both in a vanilla -current machine just to be sure that nothing was on the way... I added some interested parties, again I'm not sure where the problem is... I'm just guessing. On Mon, Sep 13, 2021 at 5:49 PM Elias M. Mariani wrote: > net/qbittorrent and net/deluge are broken (at least on amd64). > > Both are using net/libtorrent-rasterbar and devel/boost. I'm guessing > that this is the fallout from some change on the system libraries or > caused by the devel/boost update. > > I'm adding the backtrace frdsdsdom gdb for both to see if someone > with the knowledge on how to debug this can step in, or maybe just > point to where the cause might be. > > Cheers. Elias mariani@ > > net/qbittorrent > (gdb) bt > #0 thrkill () at /tmp/-:3 > #1 0x07bd21e24e1e in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x07bd21df8326 in wrterror (d=Variable "d" is not available. > ) at /usr/src/lib/libc/stdlib/malloc.c:307 > #3 0x07bd21dfbb56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, > saved_function=0x7bd21e7663a) at /usr/src/lib/libc/stdlib/malloc.c:1332 > #4 0x07bd21df8625 in ofree (argpool=0x7bd9f321ae0, > p=0x316250650a66446b, clear=0, check=0, argsz=0) at > /usr/src/lib/libc/stdlib/malloc.c:1346 > #5 0x07bd21df856b in free (ptr=0x316250650a66446b) at > /usr/src/lib/libc/stdlib/malloc.c:1470 > #6 0x07bd329eea3f in > _ZN5boost4asio6detail18completion_handlerIZNK10libtorrent14session_handle13sync_call_retINS3_13settings_packEMNS3_3aux12session_implEKFS6_vEJEEET_T0_DpOT1_EUlvE_NS0_10io_context19basic_executor_typeINSt3__19allocatorIvEELj011do_completeEPvPNS1_19scheduler_operationERKNS_6system10error_codeEm > () from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #7 0x07bd32868069 in boost::asio::detail::scheduler::do_run_one () > from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #8 0x07bd32867a91 in boost::asio::detail::scheduler::run () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #9 0x07bd329cd736 in > _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_ZN10libtorrent7session5startENS7_5flags13bitfield_flagIhNS7_17session_flags_tagEvEEONS7_14session_paramsEPN5boost4asio10io_contextEE3$_0EPvSL_ > () >from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #10 0x07bd847218e1 in _rthread_start (v=Unhandled dwarf expression > opcode 0xa3 > ) at /usr/src/lib/librthread/rthread.c:96 > #11 0x07bd21e840fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > #12 0x07bd21e840fa in __tfork_thread () at > /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 > Current language: auto; currently asm > > net/deluge > (gdb) bt > #0 thrkill () at /tmp/-:3 > #1 0x070ee2686e1e in _libc_abort () at > /usr/src/lib/libc/stdlib/abort.c:51 > #2 0x070ee265a326 in wrterror (d=Variable "d" is not available. > ) at /usr/src/lib/libc/stdlib/malloc.c:307 > #3 0x070ee265db56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, > saved_function=0x70ee26d863a) at /usr/src/lib/libc/stdlib/malloc.c:1332 > #4 0x070ee265a625 in ofree (argpool=0x70eb5edc2f0, > p=0xe14013342e6f0e0e, clear=0, check=0, argsz=0) at > /usr/src/lib/libc/stdlib/malloc.c:1346 > #5 0x070ee265a56b in free (ptr=0xe14013342e6f0e0e) at > /usr/src/lib/libc/stdlib/malloc.c:1470 > #6 0x070e96228f9b in > boost::asio::detail::thread_info_base::allocate > () >from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #7 0x070e964f38d0 in > _ZN5boost4asio6detail22deadline_timer_serviceINS1_18chrono_time_traitsINSt3__16chrono12steady_clockENS0_11wait_traitsIS6_E10async_waitINS4_6__bindIMN10libtorrent3dht11dht_trackerEFvRKNS_6system10error_codeEEJNS4_10shared_ptrISF_EERKNS4_12placeholders4__phILi1EENS0_15any_io_executorEEEvRNSA_19implementation_typeERT_RKT0_ > () from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #8 0x070e964eca45 in libtorrent::dht::dht_tracker::refresh_key () > from /usr/local/lib/libtorrent-rasterbar.so.4.0 > #9 0x070e964ec3e7 in libtorrent::dht::dht_tracker::start () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #10 0x070e963b84ed in libtorrent::aux::session_impl::start_dht () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #11 0x070e963cfdbf in > libtorrent::aux::session_impl::on_dht_router_name_lookup () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #12 0x070e96386759 in libtorrent::resolver::on_lookup () from > /usr/local/lib/libtorrent-rasterbar.so.4.0 > #13 0x070e96388f48 in >
[BUG] net/qbittorrent and net/deluge not working
net/qbittorrent and net/deluge are broken (at least on amd64). Both are using net/libtorrent-rasterbar and devel/boost. I'm guessing that this is the fallout from some change on the system libraries or caused by the devel/boost update. I'm adding the backtrace frdsdsdom gdb for both to see if someone with the knowledge on how to debug this can step in, or maybe just point to where the cause might be. Cheers. Elias mariani@ net/qbittorrent (gdb) bt #0 thrkill () at /tmp/-:3 #1 0x07bd21e24e1e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x07bd21df8326 in wrterror (d=Variable "d" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x07bd21dfbb56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, saved_function=0x7bd21e7663a) at /usr/src/lib/libc/stdlib/malloc.c:1332 #4 0x07bd21df8625 in ofree (argpool=0x7bd9f321ae0, p=0x316250650a66446b, clear=0, check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1346 #5 0x07bd21df856b in free (ptr=0x316250650a66446b) at /usr/src/lib/libc/stdlib/malloc.c:1470 #6 0x07bd329eea3f in _ZN5boost4asio6detail18completion_handlerIZNK10libtorrent14session_handle13sync_call_retINS3_13settings_packEMNS3_3aux12session_implEKFS6_vEJEEET_T0_DpOT1_EUlvE_NS0_10io_context19basic_executor_typeINSt3__19allocatorIvEELj011do_completeEPvPNS1_19scheduler_operationERKNS_6system10error_codeEm () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #7 0x07bd32868069 in boost::asio::detail::scheduler::do_run_one () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #8 0x07bd32867a91 in boost::asio::detail::scheduler::run () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #9 0x07bd329cd736 in _ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_ZN10libtorrent7session5startENS7_5flags13bitfield_flagIhNS7_17session_flags_tagEvEEONS7_14session_paramsEPN5boost4asio10io_contextEE3$_0EPvSL_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #10 0x07bd847218e1 in _rthread_start (v=Unhandled dwarf expression opcode 0xa3 ) at /usr/src/lib/librthread/rthread.c:96 #11 0x07bd21e840fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 #12 0x07bd21e840fa in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84 Current language: auto; currently asm net/deluge (gdb) bt #0 thrkill () at /tmp/-:3 #1 0x070ee2686e1e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51 #2 0x070ee265a326 in wrterror (d=Variable "d" is not available. ) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x070ee265db56 in findpool (p=0x0, argpool=0x0, foundpool=0x0, saved_function=0x70ee26d863a) at /usr/src/lib/libc/stdlib/malloc.c:1332 #4 0x070ee265a625 in ofree (argpool=0x70eb5edc2f0, p=0xe14013342e6f0e0e, clear=0, check=0, argsz=0) at /usr/src/lib/libc/stdlib/malloc.c:1346 #5 0x070ee265a56b in free (ptr=0xe14013342e6f0e0e) at /usr/src/lib/libc/stdlib/malloc.c:1470 #6 0x070e96228f9b in boost::asio::detail::thread_info_base::allocate () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #7 0x070e964f38d0 in _ZN5boost4asio6detail22deadline_timer_serviceINS1_18chrono_time_traitsINSt3__16chrono12steady_clockENS0_11wait_traitsIS6_E10async_waitINS4_6__bindIMN10libtorrent3dht11dht_trackerEFvRKNS_6system10error_codeEEJNS4_10shared_ptrISF_EERKNS4_12placeholders4__phILi1EENS0_15any_io_executorEEEvRNSA_19implementation_typeERT_RKT0_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #8 0x070e964eca45 in libtorrent::dht::dht_tracker::refresh_key () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #9 0x070e964ec3e7 in libtorrent::dht::dht_tracker::start () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #10 0x070e963b84ed in libtorrent::aux::session_impl::start_dht () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #11 0x070e963cfdbf in libtorrent::aux::session_impl::on_dht_router_name_lookup () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #12 0x070e96386759 in libtorrent::resolver::on_lookup () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #13 0x070e96388f48 in _ZNSt3__16__bindIMN10libtorrent8resolverEFvRKN5boost6system10error_codeENS3_4asio2ip23basic_resolver_iteratorINS9_3tcpEEERKNS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEJPS2_RKNS_12placeholders4__phILi1EEERKNSP_ILi2EEESK_EEclIJS7_RKNS9_22basic_resolver_resultsISB_ENS_13__bind_returnISM_NS_5tupleIJSN_SQ_ST_SI_EEENS13_IJDpOT_EEEXsr22__is_valid_bind_returnISM_S14_S18_EE5valueEE4typeES17_ () from /usr/local/lib/libtorrent-rasterbar.so.4.0 #14 0x070e96388aaa in _ZN5boost4asio6detail16resolve_query_opINS0_2ip3tcpENSt3__16__bindIMN10libtorrent8resolverEFvRKNS_6system10error_codeENS3_23basic_resolver_iteratorIS4_EERKNS5_12basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEJPS8_RKNS5_12placeholders4__phILi1EEERKNSR_ILi2EEESM_EEENS0_15any_io_executorEE11do_completeEPvPNS1_19scheduler_operationESC_m
