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
Segmentation fault when built with cxx14 #6831
Comments
@graywolf where can I find details on exactly what |
TL;DR is: It builds 1.2.14 from source code using c++14 in alpine linux (so musl-c) container, builds simple test program ( https://git.sr.ht/~graywolf/libtorrent-rasterbar-repro-6567/tree/master/item/repro.cpp ) and tries to run it.
(It's this file: https://git.sr.ht/~graywolf/libtorrent-rasterbar-repro-6567/tree/master/item/run )
|
i tried a bunch of stuff, using the above repro.cpp: all of this was on alpine edge, openssl 1.1.1q, gcc 11.2 cmake was invoked with
repro was built with
v2.0.7, cmake:
v1.2.16, cmake:
so, everything is fine. then i tried using the old configure (only present in 1.2.x):
very interesting :) the backtraces are identical from #6567 backtrace
session.cpp -> .o with automake from build log:
session.cpp -> .o with cmake (ninja file):
we see some things here:
i ran out of ideas after this, and cmake is entirely unaffected (and i *really* don't care about debugging autoconf when it's even dropped from 2.x), so i don't know why it fails. i assume b2 will similarly pass on all the variants. ftr, the failure in the backtrace (get_meta (p=p@entry=0x46ae000000000c <error: Cannot access memory at address 0x46ae000000000c>) is a result of a call to free(), and the specific cause is usually a double free (maybe) or freeing invalid memory (definitely; try with a random address and get the same failure like |
so, I suppose the next lead would be to know what the command line arguments are to the compiler when invoking it via cmake vs. configure |
the full invocation for session.cpp as an example is above, i can post the full build log of both if you like |
cmake
configure: https://img.ayaya.dev/AqjskiGews0n (too long) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
having looked over this issue again, I think there's a risk you have ABI incompatibilities because you don't user Making libtorrents ABI independent of preprocessor defines has been an ongoing project, and I can't remember if I got there in 1.2 or 2.0. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Please provide the following information
libtorrent version (or branch): 1.2.14
platform/architecture: linux/amd64 + musl-c (1.2.2) (alpine linux 3.15)
compiler and compiler version: gcc 10.3.1
please describe what symptom you see, what you would expect to see instead and
how to reproduce it.
When libtorrent-rasterbar is built with cxx14, it segfaults on adding new
torrents (well, for me it was on deluge startup, but repro is easier with
adding). This started to happen once I've updated to alpine 3.15, so new musl-c
version could have some role in this (speculation on my part). In cxx17 it
works fine. I've managed to put together reasonably short reproduction [0].
0: https://git.sr.ht/~graywolf/libtorrent-rasterbar-repro-6567
The text was updated successfully, but these errors were encountered: