Re: GDB hangs on kill or quit (after following a fork child, not detaching from the parent)

[Michael Snyder <msnyder@vmware.com>]

Pedro Alves wrote:
> On Thursday 18 December 2008 19:20:57, Michael Snyder wrote:
> 
>>> When there are forks involved, linux_nat_kill calls into linux_fork_killall
>>> to do the killing.  But, when following a fork child, and not
>>> detaching from the parent, we defer adding the child fork to the
>>> list of forks (which is confusing IMHO, see below),
>> Do you have any intuition as to why we did that?
>> I don't remember.  Could it have been related to the
>> checkpoint case?
>>
>> Otherwise it could simply have been an oversight...
> 
> Yeah, I should have mentioned it before:  At first I also
> thought it was checkpoints related, then I noticed that
> when 'set follow-fork-mode' is child, checkpoints are broken
> for other reasons.  It may well be that it always was (broken):

That would not be at all surprising.  Since checkpoints use
forks as underlying implementation, I would not expect that
checkpoint and follow-child would play well together.



> I think that when checkpointing, we should always "follow"
> the parent anyway; and that the checkpoints support should be
> better insulated from the multi forks support, so that the
> multi-forks support can grow into full multi-process support.

Agreed.  For starters, we might just document that checkpoints
are not defined to work for forking processes (or for multi-
threaded ones, for that matter).

> 
>> I like your results, and your code changes look fine.
>> Can you confirm that it doesn't adversely affect the
>> checkpoint testsuites?
> 
> Yep, had done that.  No regressions in the checkpoints tests, or in
> the rest of the testsuite.
> 
> I'll go check it in then.

OK.