FS#78173 - [gcc] C++ 2023 std::stacktrace segfault

Attached to Project: Arch Linux
Opened by Hugo Sales (someonewithpc) - Tuesday, 11 April 2023, 20:42 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:14 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To freswa (frederik)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: using libbacktrace causes a segfault


Additional info:
* package version(s): gcc 12.2.1-2 gcc-libs 12.2.1-2

Steps to reproduce:

Compile the following:

```
#include <stacktrace>
#include <iostream>

void foo() {
auto trace = std::stacktrace::current();
std::cout << std::to_string(trace) << '\n';
}

int main() {
foo();
}
/*
expected output:
0# foo() at /app/example.cpp:5
1# at /app/example.cpp:10
2# at :0
3# at :0
4#
*/
```

with:

```
g++ --std=gnu++23 backtrace.cpp -lstdc++_libbacktrace -o backtrace
```

And execute it

```
$ ./backtrace
Segmentation fault (core dumped)
```

However, with gcc built from source with `./configure --enable-libstdcxx-backtrace=yes`, and installed to `./bin`, compiling with

```
$ ./bin/usr/local/bin/g++ --std=gnu++23 -I ./bin/usr/local/lib64/ backtrace.cpp -lstdc++_libbacktrace -o backtrace
$ LD_LIBRARY_PATH=./bin/usr/local/lib64/ ./backtrace
0# foo() at :0
1# main at :0
2# at :0
3# at :0
4# _start at :0
5#
```

Yielding the expected result. The segfault happens when accessing the trace (by converting to a string), not when constructing.

This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:14 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/gcc/issues/1
Comment by Toolybird (Toolybird) - Wednesday, 12 April 2023, 03:52 GMT Comment by Toolybird (Toolybird) - Thursday, 13 April 2023, 06:31 GMT
> However, with gcc built from source with `./configure --enable-libstdcxx-backtrace=yes`, and installed to `./bin`

You haven't specified the *exact* commands nor the source commit hash you used to build your local GCC. Additionally, installing to ./bin suggests you haven't built it inside a clean chroot...and therefore your *FLAGS are probably different. I'm guessing the Arch build *FLAGS are what is causing the issue and if so, it should be reported upstream so they can fix it.

Either way, this is a newish and experimental feature and unless you can pinpoint the exact cause, it's unlikely to be fixed. GCC13 is just around the corner so the situation there might be different.
Comment by Hugo Sales (someonewithpc) - Tuesday, 18 April 2023, 20:59 GMT
To build it locally, I simply did `./configure --enable-libstdcxx-backtrace=yes; make -j32; make DESTDIR=$PWD/bin/ install` with commit d2ee685f6fa922e97908ed998d14def9e01e1e4e

I've since built and installed gcc-git 14.0.0 20230418 (experimental) (14.0.0_r199944.gd2ee685f6fa-1) which seems to have used commit d2ee685f6fa922e97908ed998d14def9e01e1e4e but while it doesn't segfault anymore, the stacktrace does not include symbols:

```
$ g++ -g --std=c++23 backtrace.cpp -lstdc++_libbacktrace -o backtrace && ./backtrace
0# at :32765
1# at :32765
2# at :32765
3# at :32765
4# at :32765
5#

$ ~/projects/gcc/gcc-build/bin/usr/local/bin/g++ -g --std=c++23 backtrace.cpp -lstdc++_libbacktrace -o backtrace && ./backtrace
0# foo() at /home/hugo/.scratch/backtrace.cpp:5
1# main at /home/hugo/.scratch/backtrace.cpp:10
2# at :0
3# at :0
4# _start at :0
5#
```

As far as I can tell from reading the Makefiles, the local build is using `-g -O2` but I can't really tell what flags the one build for gcc-git from the repo is using, as the Makefile seems to get deleted. From the PKGBUILD, it seems to simply be `-O2`



Comment by Toolybird (Toolybird) - Tuesday, 18 April 2023, 22:51 GMT
Ok, so your GCC wasn't bootstrapped which means the *FLAGS will definitely be different. Building "simply" is quite a bit different to how Arch builds it for the distro. See the Arch GCC PKGBUILD and also  FS#71777  for an idea on how complicated it gets.

Edit: Sorry, I might have the above slightly wrong. Haven't played with GCC for a while...it is actually bootstrapped by default. Either way, we can revisit this issue when GCC13 hits the shelves...
Comment by Hugo Sales (someonewithpc) - Sunday, 07 May 2023, 19:40 GMT
With `gcc 13.1.1-1` it no longer segfaults, but there's also no file information:

~/scratch/$ g++ --std=gnu++23 -ggdb3 backtrace.cpp -lstdc++_libbacktrace -o backtrace
~/scratch/$ ./backtrace
0# at :32767
1# at :32767
2# at :32767
3# at :32767
4# at :32767
5#

Comment by Toolybird (Toolybird) - Sunday, 07 May 2023, 22:16 GMT
It would be interesting to see the output on Fedora 38 which has gcc-13.
Comment by Hugo Sales (someonewithpc) - Friday, 09 June 2023, 10:31 GMT
I ran it in a VM and got the expected output:

[liveuser@localhost-live ~]$ g++ --std=gnu++23 test.cpp -ggdb -lstdc++_libbacktrace -o backtrace
[liveuser@localhost-live ~]$ ./backtrace
0# foo() at /home/liveuser/test.cpp:5
1# main at /home/liveuser/test.cpp:10
2# at :0
3# at :0
4# _start at :0
5#

With version
[liveuser@localhost-live ~]$ g++ --version
g++ (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2)

Also, it still doesn't work in Arch with version g++ (GCC) 13.1.1 20230429

Loading...