GDB loses running state of inferior

GDB loses running state of inferior

[Andreas Schwab]

When an error occurs during startup of the child the running state of
the child is lost and gdb is refusing to continue it:

(gdb) b *0
Breakpoint 1 at 0x0
(gdb) r
Starting program: /bin/cat 
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x0: Input/output error.

(gdb) c
Continuing.
Cannot execute this command while the selected thread is running.

Andreas.

2008-11-20  Andreas Schwab  <schwab@suse.de>

	* fork-child.c (startup_inferior): Don't lose running state of
	inferior.

--- gdb/fork-child.c.~1.47.~	2008-11-10 11:25:09.000000000 +0100
+++ gdb/fork-child.c	2008-11-20 14:27:26.000000000 +0100
@@ -494,6 +494,9 @@ startup_inferior (int ntraps)
 	resume_ptid = pid_to_ptid (-1);
       else
 	resume_ptid = event_ptid;
+      /* Update running state now, in case an error occurs during
+	 resume.  */
+      set_running (resume_ptid, 0);
 
       if (resume_signal != TARGET_SIGNAL_TRAP)
 	{

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GDB loses running state of inferior

[Pedro Alves]

On Thursday 20 November 2008 14:33:14, Andreas Schwab wrote:
> When an error occurs during startup of the child the running state of
> the child is lost and gdb is refusing to continue it:

> (gdb) c
> Continuing.
> Cannot execute this command while the selected thread is running.
> 

> 2008-11-20  Andreas Schwab  <schwab@suse.de>
> 
> 	* fork-child.c (startup_inferior): Don't lose running state of
> 	inferior.

Thanks.  Could you hold on to this a bit?  This will make it so that
MI outputs more *running, *stopped notifications when going through
the shell on startup.

This a problem that can happen in several other places, and I've
been solving them with a cleanup and a new function that sets
the threads' running state (tp->state_) from the tp->executing_ property.
I'll have to clean it up a bit to submit, then we can fix this too.

> 
> --- gdb/fork-child.c.~1.47.~	2008-11-10 11:25:09.000000000 +0100
> +++ gdb/fork-child.c	2008-11-20 14:27:26.000000000 +0100
> @@ -494,6 +494,9 @@ startup_inferior (int ntraps)
>  	resume_ptid = pid_to_ptid (-1);
>        else
>  	resume_ptid = event_ptid;
> +      /* Update running state now, in case an error occurs during
> +	 resume.  */
> +      set_running (resume_ptid, 0);
>  
>        if (resume_signal != TARGET_SIGNAL_TRAP)
>  	{

-- 
Pedro Alves