Re: [RFA] fix crasher on detach command

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> On Monday 07 June 2010 20:08:51, Pedro Alves wrote:
>> On Monday 07 June 2010 20:00:04, Michael Snyder wrote:
>>>> Then we need to fix that, instead of adding workarounds in other
>>>> areas.
>>> I'm not sure how feasible that is.  At this point I've had to use a
>>> ^C^C to get out of a failing attach (target remote), and I'm hoping to
>>> use the "detach" to cancel out any remaining inconsistent state.
>>> The ^C^C handler can't necessarily do it by itself, 'cause from its
>>> point of view, you don't really know what state you're in or what
>>> state you want to be in.
>> It's feasible.  remote_open_1 + remote_start_remote and remote_close
>> (usually from pop_target calls within remote.c) are all designed for
>> this to not happen, but clearly there's a bug somewhere.  It just
>> sounds like there's something not exception safe that should be.
> 
> To be a bit clearer --
> 
>  you've said that the pid was left as 42000 (I assume you meant
> inferior_ptid, but that find_inferior no longer finds that inferior.
> Where is the current inferior getting it's pid cleared out?  Why
> aren't we clearing inferior_ptid as well?

What do you mean by "the current inferior"?  I thought that was
inferior_ptid (which is "magic_null_ptid", (42000, 1, -1).