[RFA] fix crasher on detach command
Michael Snyder
msnyder@vmware.com
Mon Jun 7 23:50:00 GMT 2010
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).
More information about the Gdb-patches
mailing list