When building gdb with guile, I run into a bunch of testsuite failures:
FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout)
FAIL: gdb.gdb/python-helper.exp: loading test binary into inner GDB (got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: pretty print type->main_type for DWARF type
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
FAIL: gdb.gdb/selftest.exp: send ^C to child process (timeout)
FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout)
FAIL: gdb.gdb/selftest.exp: send ^C to child process again (timeout)
FAIL: gdb.gdb/selftest.exp: thread 1 (timeout)
FAIL: gdb.gdb/selftest.exp: backtrace through signal handler (timeout)
In more detail:
Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.^M
0x00007ffff71f1aa3 in ?? () from /lib64/libgc.so.1^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: start inner gdb (timeout)
This is actually documented behaviour ( https://hboehm.info/gc/debugging.html ).
So there's nothing wrong with gdb. Building gdb with guile makes gdb "a program that uses libgc1". The same behaviour can be reproduced by debugging a simple:
$ cat test.c
$ gcc test.c -lgc
We could update the test-case to continue when hitting the SIGSEGV.
The documented advise to deal with this suggests:
(gdb) handle SIGSEGV SIGBUS nostop noprint"
(In reply to Tom de Vries from comment #1)
> We could update the test-case to continue when hitting the SIGSEGV.
> The documented advise to deal with this suggests:
> (gdb) handle SIGSEGV SIGBUS nostop noprint"
We could even try to do this automagically when detecting that we debug a process using libgc1.
[ FTR, originally filed at https://bugzilla.opensuse.org/show_bug.cgi?id=1153239 ]
(In reply to Tom de Vries from comment #2)
> We could even try to do this automagically when detecting that we debug a
> process using libgc1.
I don't think gdb should do this itself.
However, libgc could ship a python script to do it.
Although I thought I heard that libgc changed its probing
strategy to avoid the SEGV.
The master branch has been updated by Tom Tromey <email@example.com>:
Author: Tom Tromey <firstname.lastname@example.org>
Date: Thu Dec 15 14:12:05 2022 -0700
Handle SIGSEGV in gdb selftests
The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325. Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing. This unexpected stop confuses the tests and
causes repeated timeouts.
This patch adapts the two failing tests. This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11