Re: RFA: linux-thread.c change (fixes hang on startup)

[Eric Paire <paire at ri dot silicomp dot fr>]

> The code in question looks like this:
> 
>   /* initialize SIGCHLD mask */
>   sigemptyset (&linuxthreads_wait_mask);
>   sigaddset (&linuxthreads_wait_mask, SIGCHLD);
> 
>   /* Use SIG_BLOCK to block receipt of SIGCHLD.
>      The block_mask will allow us to wait for this signal explicitly.  */
>   sigprocmask(SIG_BLOCK, 
> 	      &linuxthreads_wait_mask, 
> 	      &linuxthreads_block_mask);
> 
> What this code fails to take into account is what happens if SIGCHLD is
> already being blocked.  (Perhaps set that way from some other part of
> gdb.)  If this is the case, then setting linuxthreads_block_mask to
> the old signal mask (prior to blocking the SIGCHLD with SIG_BLOCK)
> results in a mask with SIGCHLD blocked.
> 
> This is clearly a problem because the loop noted above will get stuck
> in sigsuspend() if it doesn't manage to find a change in a child status
> on the first iteration.
> 
> This leads me to the patch below and I hereby request approval for
> committing it.  I have run the test suite on Linux and have observed
> no regressions as a result of this change.
> 
I privately discussed the SIGCHLD management point with Michael, as this was
one major change in the LinuxThread support behaviour I wrote code for. My
only problem with your patch is that if SIGCHLD is blocked at that time, it
should have been blocked intentionally by other part of GDB, and if SIGCHLD
has not yet been unblocked, then this is a bug to fix in the right part
of GDB, and not in the LinuxThread support, because other parts of GDB
dealing with SIGCHLD [un]masking will also have to support the fix you
propose.

So, I would suggest that (thanks to your program which exhibits consistently
the problem) you try to track down the signal status in 'gdb_init()' and try
to discover what part of GDB is incorrectly managing SIGCHLD. After having
downloaded the latest GDB snapshot and looked at the source, I have not
been able to see any place where the SIGCHLD is being blocked before calling
'_initialize_linuxthreads()', but you should be able to discover that
quickly with your test program (perhaps in the 'pre_init_ui_hook' if you use
an UI).

Could you just check that for me. Thanks in advance,
-Eric
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web  : http://www.ri.silicomp.com/~paire  | Group SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com         | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71               | F-38610 Gieres
Fax  : +33 (0) 476 51 05 32               | FRANCE