linux-low.c: stop_all_processes vs longjmp snafu?

linux-low.c: stop_all_processes vs longjmp snafu?

[Doug Evans]

linux-low.c:stop_all_processes is the only place that sets stopping_threads:

static void
stop_all_processes (void)
{
  stopping_threads = 1;
  for_each_inferior (&all_processes, send_sigstop);
  for_each_inferior (&all_processes, wait_for_sigstop);
  stopping_threads = 0;
}

and all functions that test stopping_threads can throw an error
(call longjmp).

I'm guessing fixing this is waiting on someone to remove stopping_threads,
right?

Re: linux-low.c: stop_all_processes vs longjmp snafu?

[Doug Evans]

On Fri, Dec 12, 2008 at 4:13 PM, Doug Evans <dje@google.com> wrote:
> linux-low.c:stop_all_processes is the only place that sets stopping_threads:
>
> static void
> stop_all_processes (void)
> {
>  stopping_threads = 1;
>  for_each_inferior (&all_processes, send_sigstop);
>  for_each_inferior (&all_processes, wait_for_sigstop);
>  stopping_threads = 0;
> }
>
> and all functions that test stopping_threads can throw an error
> (call longjmp).
>
> I'm guessing fixing this is waiting on someone to remove stopping_threads,
> right?

I was thinking that we don't want to support nested setjmps.  But in a
case like this do we want to continue to try to stop all processes
even if stopping one of them throws an error?  [assuming we're keeping
setjmp and not rewriting gdbserver in c++ ...]

Re: linux-low.c: stop_all_processes vs longjmp snafu?

[Daniel Jacobowitz]

On Sat, Dec 13, 2008 at 11:23:44AM -0800, Doug Evans wrote:
> I was thinking that we don't want to support nested setjmps.  But in a
> case like this do we want to continue to try to stop all processes
> even if stopping one of them throws an error?  [assuming we're keeping
> setjmp and not rewriting gdbserver in c++ ...]

I'm more thinking that we should do actual error handling in
gdbserver, and ditch the longjmp based version.  It almost never
works.  It tends to leave state inconsistent; and up until recently
(or maybe still) it left the protocol state machine in the wrong state.

-- 
Daniel Jacobowitz
CodeSourcery