Re: [RFA] fix crasher on detach command

[Michael Snyder <msnyder at vmware dot 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).