GDB hangs on kill or quit (after following a fork child, not detaching from the parent)
Michael Snyder
msnyder@vmware.com
Thu Dec 18 21:47:00 GMT 2008
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.
More information about the Gdb-patches
mailing list