GDB-Guile vs. libgc 7.4 marker threads

[ludo@gnu.org (Ludovic Courtès)]

[+ Andy :-)]

Doug Evans <xdje42@gmail.com> skribis:

> On Sun, May 4, 2014 at 11:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Sun, 04 May 2014 21:59:08 +0200
>>> From: Tillmann Karras <tillmann@selfnet.de>
>>> Cc: gdb-patches@sourceware.org
>>>
>>> On 2014-04-28 00:15, Doug Evans wrote:
>>> > If you're running gdb under gdb, and the child gdb is hanging,
>>> > can you type Ctrl-C when it hangs, and then obtain a backtrace of the
>>> > child gdb?
>>>
>>> Pressing Ctrl-C just prints "[New Thread 0x7ffff4b6f700 (LWP 14601)]"
>>> but I don't get any prompt.
>>
>> My crystal ball says that Ctrl-C causes Guile to start its signal
>> delivery thread, which is the reason for the "New Thread" message you
>> see.
>>
>>> > It's been suggested to give the following a try.
>>> > Does that fix things for you?
>>> >
>>> > bash$ export GC_MARKERS=1
>>> >
>>> > before starting gdb
>>> > It's a workaround for a libgc 7.4.0 bug.
>>> > I verified my arch-linux has libgc 7.4.0, but I may have just gotten
>>> > lucky.
>>>
>>> Yes, "gdb -ex 'set environment GC_MARKERS 1' -ex r gdb" makes it work
>>> for me. (Maybe your test VM had only one core?)
>>
>> What bug is that in libgc, and what are its symptoms?
>
> A google search for libgc 7.4 GC_MARKERS found this:
>
> 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, 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.

Probably the GC_MARKERS hack linked above should be applied to GDB as
well.  WDYT?

Thanks,
Ludo’.