mourning the inferiour error

[Doug Evans]

On Wed, Jul 29, 2009 at 6:28 AM, Joel Sherrill<joel.sherrill@oarcorp.com> wrote:
> Hi,
>
> I have been debugging using a simulator external to
> gdb.  If you <ctl>-c the simulator first and then
> quit gdb, you reliably get this.  I understand that
> if you were debugging natively or with a simulator
> internal to gdb, this would be a VERY bad thing to
> happen.  But since the target is external, this
> scenario is somewhat expected.  This is certainly
> not a case where one wants a gdb core dump.
>
> Is there anyway to know the target is external to
> gdb and the connection went away? Then this
> scenario could be dealt with a little more
> gracefully.
>
> ========================================
> (gdb) q
> The program is running.  Quit anyway (and kill it)? (y or n) y
> Remote connection closed
>
> ../../gdb-6.8.50.20090629/gdb/target.c:2094: internal-error: could not find
> a target to follow mourn inferiour
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n) y
>
> ../../gdb-6.8.50.20090629/gdb/target.c:2094: internal-error: could not find
> a target to follow mourn inferiour
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Create a core file of GDB? (y or n) n
> ============================================

Hi.

Assuming you're using "target remote" (or extended-remote),
I tried recreating the failure with gdbserver, but couldn't.
20090629 is moderately old given all the changes going in.

Are you using target remote/extended-remote?
Could you maybe try with cvs head?