This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]