Re: [patch] linux_nat_kill() compat. with linux-2.4.x

[Pedro Alves <palves at redhat dot com>]

On 06/06/2014 09:15 PM, Jan Kratochvil wrote:
> On Wed, 21 May 2014 14:49:43 +0200, Pedro Alves wrote:
>> On 03/16/2014 01:59 PM, Jan Kratochvil wrote:
>>> diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
>>> index b615423..ec84188 100644
>>> --- a/gdb/linux-nat.c
>>> +++ b/gdb/linux-nat.c
>>> @@ -3777,8 +3777,15 @@ linux_nat_kill (struct target_ops *ops)
>>>      {
>>>        ptid_t ptid = pid_to_ptid (ptid_get_pid (inferior_ptid));
>>>  
>>> +      /* Kill all LWP's before trying to stop them.  In rare cases the
>>> +	 lwp_info state may not match the inferior and
>>> +	 stop_wait_callback could lock up.  */
>>
>> Hmm, I find this comment confusing and not really enlightening.
>> What sort of rare cases?  It that PR15713?  Best just fix that.
>> I've sent a patch:
>> https://sourceware.org/ml/gdb-patches/2014-05/msg00473.html
> 
> The reproducible case is that PR15713 and it is sure great you have fixed it.

Great.

> Fine with dropping the patch although I still do not find it obvious the patch
> is no longer relevant.

Thanks, I'd rather drop it.

> FSF GDB now relies on fact that ptraced inferior state always matches
> lp->stopped and there is a matching signal to wait for etc.  In some cases GDB
> hangs during quit (and inferiors cleanup) and one has to kill GDB itself.
> Reasons are not known to me as I do not know how to reproduce it.
> (It may be also possible all such reasons have been fixed now.)

I think any case that this bullet proofing patch could work around
have now been fixed.

> It also may hang somewhere else and not in linux_nat_kill().

Right.  I'd say it's much more likely (even though not very likely, tbc)
that we see hangs elsewhere than in linux_nat_kill now.  E.g., GDB core's
is_executing state getting out of sync with lwp->stopped.

> This patch made GDB foolproof against any state of inferior when killing the
> inferior so that GDB could no longer hang.  But it would hide some possible
> remaining bugs in the code (which may be causing the GDB hangs).

Right, I'd rather just fix the GDB bugs, and only consider such a patch
if we need to work around a kernel bug (though I'd rather just
ignore very old kernels like 2.4 by now).

-- 
Pedro Alves