Bug 29325

Summary: [gdb/guile] Fails in gdb.gdb/{python-helper,selftest}.exp when building with guile (sigsegv in libgc1)
Product: gdb Reporter: Tom de Vries <vries>
Component: testsuiteAssignee: Tom Tromey <tromey>
Status: RESOLVED FIXED    
Severity: normal CC: tromey
Priority: P2    
Version: HEAD   
Target Milestone: 14.1   
Host: Target:
Build: Last reconfirmed:

Description Tom de Vries 2022-07-07 05:56:28 UTC 
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
#include "gc.h"

int
main (void)
{
  GC_INIT ();
  return 0;
}
...
compiled like:
...
$ gcc test.c -lgc
...
Comment 1 Tom de Vries 2022-07-07 05:58:31 UTC 
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"
...
Comment 2 Tom de Vries 2022-07-07 06:16:30 UTC 
(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.
Comment 3 Tom de Vries 2022-07-07 06:17:47 UTC 
[ FTR, originally filed at https://bugzilla.opensuse.org/show_bug.cgi?id=1153239 ]
Comment 4 Tom Tromey 2022-12-16 16:09:10 UTC 
(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.
Comment 6 cvs-commit@gcc.gnu.org 2022-12-27 17:22:25 UTC 
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=59132fd9777442eea8c05c6b4b96cee03c6273b3

commit 59132fd9777442eea8c05c6b4b96cee03c6273b3
Author: Tom Tromey <tromey@adacore.com>
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
    seconds.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
Comment 7 Tom Tromey 2022-12-27 19:31:22 UTC 
Fixed.