Re: GDB-Guile vs. libgc 7.4 marker threads

Ludovic Courtès
2014-05-13T15:53:35Z

Eli Zaretskii <eliz@gnu.org> skribis:

>> From: ludo@gnu.org (Ludovic Courtès)
>> Cc: Eli Zaretskii <eliz@gnu.org>, Tillmann Karras <tillmann@selfnet.de>, "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>, Andy Wingo <wingo@pobox.com>
>> Date: Mon, 12 May 2014 10:00:22 +0200
>>
>> > https://lists.gnu.org/archive/html/guile-commits/2014-04/msg00051.html
>>
>> Yes, but note that this commit is for Guile 2.2.
>>
>> That said, although Guile 2.0 builds and runs fine with 7.4
>
> Are you saying that Guile 2.0.x does not suffer from the bug in
> libgc-7.4.0?

Yes, in my experience.

>> I noticed that GDB-Guile is confused when there are several marker
>> threads. Thus, we have to set GC_MARKERS=1 when running Guile-GDB
>> with Guile 2.0 on libgc 7.4.
>
> Are you sure this confusion is related to the same libgc issue?

What I know is that setting GC_MARKERS=1 allows GDB-Guile with libgc
7.4.0 to work flawlessly, whereas it otherwise hangs when not doing
that.

For instance, with GC_MARKERS unset (my machine has 4 cores, so libgc
spawns 3 marker threads), I can run:

--8<---------------cut here---------------start------------->8---
$ ./gdb --args guile
GNU gdb (GDB) 7.7.50.20140505-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from guile...done.
(gdb) r
Starting program: /home/ludo/soft/bin/guile
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/libthread_db.so.1".
--8<---------------cut here---------------end--------------->8---

and it hangs right here.

The backtrace of gdb at this point is:

--8<---------------cut here---------------start------------->8---
(gdb) bt
#0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
#1 __GI___sigsuspend (set=set@entry=0xb702c0 <suspend_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#2 0x0000000000451ced in linux_nat_wait_1 (ops=<optimized out>, target_options=0, ourstatus=0x7fffee48a910,
ptid=...) at linux-nat.c:3418
#3 linux_nat_wait (ops=<optimized out>, ptid=..., ourstatus=0x7fffee48a910, target_options=0)
at linux-nat.c:3654
#4 0x0000000000458d66 in thread_db_wait (ops=<optimized out>, ptid=..., ourstatus=0x7fffee48a910, options=0)
at linux-thread-db.c:1486
#5 0x000000000056f59d in delegate_wait (self=<optimized out>, arg1=..., arg2=<optimized out>,
arg3=<optimized out>) at target-delegates.c:60
#6 0x0000000000576d33 in target_wait (ptid=..., status=status@entry=0x7fffee48a910, options=options@entry=0)
at target.c:2103
#7 0x0000000000540f95 in wait_for_inferior () at infrun.c:2810
#8 0x00000000005411ef in proceed (addr=<optimized out>, siggnal=siggnal@entry=GDB_SIGNAL_0, step=step@entry=0)
at infrun.c:2371
#9 0x00000000005367dd in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=<optimized out>) at infcmd.c:631
#10 0x000000000060a08b in execute_command (p=<optimized out>, p@entry=0x224e6c0 "", from_tty=1) at top.c:460
#11 0x00000000005567d5 in command_handler (command=0x224e6c0 "") at event-top.c:437
#12 0x0000000000556db4 in command_line_handler (rl=<optimized out>) at event-top.c:634
#13 0x0000000000650ac0 in rl_callback_read_char () at callback.c:220
#14 0x0000000000556839 in rl_callback_read_char_wrapper (client_data=<optimized out>) at event-top.c:166
#15 0x0000000000555441 in process_event () at event-loop.c:342
#16 0x000000000055580a in gdb_do_one_event () at event-loop.c:394
#17 0x0000000000555a5e in start_event_loop () at event-loop.c:431
#18 0x000000000054f453 in captured_command_loop (data=data@entry=0x0) at main.c:266
#19 0x000000000054caca in catch_errors (func=func@entry=0x54f440 <captured_command_loop>,
func_args=func_args@entry=0x0, errstring=errstring@entry=0x712212 "", mask=mask@entry=RETURN_MASK_ALL)
at exceptions.c:524
#20 0x00000000005501b6 in captured_main (data=data@entry=0x7fffee48adb0) at main.c:1054
#21 0x000000000054caca in catch_errors (func=func@entry=0x54f740 <captured_main>,
func_args=func_args@entry=0x7fffee48adb0, errstring=errstring@entry=0x712212 "",
mask=mask@entry=RETURN_MASK_ALL) at exceptions.c:524
#22 0x000000000055067b in gdb_main (args=args@entry=0x7fffee48adb0) at main.c:1062
#23 0x000000000040b645 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:33
(gdb) info threads
Id Target Id Frame
4 Thread 0x7f0e56efb700 (LWP 17172) "gdb" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
3 Thread 0x7f0e566aa700 (LWP 17173) "gdb" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
2 Thread 0x7f0e55e59700 (LWP 17174) "gdb" pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
* 1 Thread 0x7f0e5fb93740 (LWP 17170) "gdb" 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
(gdb) thread 2
[Switching to thread 2 (Thread 0x7f0e55e59700 (LWP 17174))]
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
185 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory.
(gdb) bt
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f0e5ea28907 in GC_wait_marker () at pthread_support.c:2036
#2 0x00007f0e5ea1f31a in GC_help_marker (my_mark_no=my_mark_no@entry=11) at mark.c:1160
#3 0x00007f0e5ea26f5c in GC_mark_thread (id=<optimized out>) at pthread_support.c:389
#4 0x00007f0e5e010052 in start_thread (arg=0x7f0e55e59700) at pthread_create.c:309
#5 0x00007f0e5e521e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) thread 1
[Switching to thread 1 (Thread 0x7f0e5fb93740 (LWP 17170))]
#0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
31 ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
(gdb) finish
Run till exit from #0 0x00007f0e5e4717a2 in do_sigsuspend (set=0xb702c0 <suspend_mask>)
at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
--8<---------------cut here---------------end--------------->8---

and ‘sigsuspend’ never returns. So it looks like it’s losing some
SIGCHLDs, which would be unrelated to the problem we’re seeing with
Guile 2.2.

libgc installs handlers for SIGPWR and SIGXCPU, which it uses to
coordinate stop-the-world GCs, but that doesn’t interfere AFAICS (and
it’s the case regardless of whether there are 1 or more marker threads.)

I’ve investigated a bit but can’t find any why/how libgc could interfere
with gdb’s signal handling. Ideas?

Ludo’.