Re: [RFA] lin-lwp.c change to avoid obscure hanging

[Michael Snyder <msnyder@redhat.com>]

"Paul N. Hilfinger" wrote:
> 
> Under certain obscure conditions, GDB will hang when continuing a program
> that uses GNU/Linux LWPs.  For example, one set of circumstances that
> were uncovered in an Ada program were:
> 
> 1. A breakpoint is tripped over in thread A.
> 
> 2. When all threads are stopped, it turns out that thread B != A has received
>    a signal (specifically SIG32, which is apparently used by the thread
>    package).  This signal, furthermore, is "not of interest" to GDB
>    (as if according to 'set handle SIG32 pass noprint nostop').
>    A and B here stand for integer literals, of course.
> 
> 3. The user executes the commands
>      delete
>      thread B
>      continue

This isn't really a sensable thing to do anyway.
Probably the user is imagining that this will cause
thread B to be treated in some way specially (eg. 
resumed before the others), but it will not
(or at least it should not).

> I am uncertain as to the proper fix is for this, but I have provided
> one possibility below (that works for us).  The long ugly comment
> will, I hope, prompt the more experienced among you to resolve the
> outstanding questions.

Puzzling: shouldn't "prepare_to_proceed" be handling this?
In theory, before gdb actually resumes the child, it should
restore the "current thread" to be thread A.





> 
> 2002-04-10  Paul N. Hilfinger  <hilfingr@otisco.mckusick.com>
> 
>         * lin-lwp.c (lin_lwp_resume): Pass unprocessed signals to the
>         selected lwp, if GDB is not interested in them, and no specific
>         signal is requested.  Fixes regression (hanging) displayed by
>         9820-005__task_switch.
> 
> Index: gdb/lin-lwp.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/lin-lwp.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 lin-lwp.c
> --- gdb/lin-lwp.c       31 Mar 2002 15:10:38 -0000      1.34
> +++ gdb/lin-lwp.c       13 Apr 2002 08:41:20 -0000
> @@ -605,6 +605,32 @@ lin_lwp_resume (ptid_t ptid, int step, e
>        /* Mark this LWP as resumed.  */
>        lp->resumed = 1;
> 
> +      if (WIFSTOPPED (lp->status))
> +       {
> +         enum target_signal stopsig
> +           = target_signal_from_host (WSTOPSIG (lp->status));
> +
> +         /* If we have a signal GDB is not interested in, then
> +            arrange to pass it to the process without comment.  This
> +            should be able to happen only when one changes threads
> +            before continuing.  To be conservative, we do this only
> +            if signo is TARGET_SIGNAL_0.
> +            FIXME: hilfinger/2002-04-10: But this means we can't
> +            switch to this thread and clear its signal.  We could try
> +            simply not resuming when lp->status is non-zero, and
> +            leave it to lin_lwp_wait to catch the unhandled signal,
> +            but it will resume ONLY this thread (see Kettenis's FIXME
> +            in lin_lwp_wait), and this is not always right. */
> +
> +         if (signo == TARGET_SIGNAL_0
> +             && signal_stop_state (stopsig) == 0
> +             && signal_print_state (stopsig) == 0
> +             && signal_pass_state (stopsig) == 1)
> +           {
> +             signo = stopsig;
> +             lp->status = 0;
> +           }
> +       }
>        /* If we have a pending wait status for this thread, there is no
>           point in resuming the process.  */
>        if (lp->status)