Re: RFC: fix crash when inferior exits during "continue"

[Pedro Alves <palves at redhat dot com>]

On 02/14/2012 01:44 PM, Gary Benson wrote:
> Tom Tromey wrote:
>>>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>>
>> Jan> Maybe during make_cleanup_restore_current_thread temporarily
>> Jan> remember + clear inferior-> removable instead.
>>
>> I hadn't considered this, but it is an interesting idea.
>>
>> It would have the maybe odd effect of leaving the dead inferior
>> around as long as it was selected.  Maybe this is even the clearest
>> thing to do; I am not sure.
>>
>> Do you (or anybody) have an opinion on which is better?
> 
> I'm not especially familiar with this area of GDB, but I prefer the
> idea of holding the selection on the dead inferior over arbitrarily
> selecting another.  I think the latter could be confusing.

Yeah.  We also don't randomly switch to another thread if the previous
selected thread exits (and this is the reason we have "exited" threads).
Otherwise, if the user is typing

(gdb) some_command_that_applies_to_the_current_thread <enter>

and the current thread disappears while the user is typing,
the command ends up being applied to a random thread, which is
not good.

In this case, we need to step back a little.  Why are we removing
the inferior at all?  The whole idea of inf->removable was that
when you run, say, "make check" under gdb, and you follow all forks,
you don't want to end up with 1000 inferiors loaded.  So gdb marks
inferiors/forks that appeared not by explicit user action
as "removable".  Those that are removable are pruned by prune_inferiors,
roughly whenever we handle an event that gives the prompt to the
user (at the end of normal_stop).

But in this case, the user explicitly switched to a "removable"
inferior, and then resumed (inferior 2; continue; <crash, inf2 is gone>)

  So we may consider two things:

 - The inferior should no longer be "removable".  The user has
   expressed interest in it.

 - Make make_cleanup_restore_current_thread "lock" the current
   inferior, so it isn't removed even if it is "removable".
   We do something similar for threads -- That's the whole reason
   for thread_info->refcount.  (This is also Jan's suggestion.)

-- 
Pedro Alves