On Tue, Aug 26, 2014 at 1:14 AM, Doug Evans <xdj...@gmail.com> wrote: > Hi. > > I think(!) I understand why gdb is hanging when used with libgc 7.4.x. > This is gdb bug 17247. > https://sourceware.org/bugzilla/show_bug.cgi?id=17247#c30 > > First, libgc 7.4.x was the first release to default PARALLEL_MARK to > on, so I'm guessing the same "bug" exists in 7.2, it's just not > visible unless one builds libgc with --enable-parallel-mark. > > gdb/linux-nat.c calls sigsuspend when the inferior is running and gdb > needs to wait for it to stop. > gdb is waiting on a SIGCHLD at this point. > > However, if the SIGCHLD goes to a different thread, say the guile > finalizer thread or a libgc marker thread then the sigsuspend that gdb > calls doesn't wake up and gdb is hung. > > So question: Any suggestions for how to approach this?
Since threads inherit the sigmask of their creator one thing I could do, I think, is block SIGCHLD before initializing Guile and then unblock it afterwards. The four threads I see being created during Guile initialization (3 marker threads plus Guile's finalizer thread) are created during that time. Question: Does Guile create any threads lazily? [I'm referring to internal Guile-created threads. Users who create their own threads are on their own, at least for now. IWBN though if there were a mechanism to have all threads that Guile created have SIGCHLD initially blocked. I wouildn't make it SIGCHLD-specific of course - just have a way to augment the initial sigmask of newly created threads.]
