This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Follow-fork-mode and inferiors
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: Kevin Pouget <kevin dot pouget at gmail dot com>
- Date: Wed, 1 Jun 2011 16:29:18 +0100
- Subject: Re: Follow-fork-mode and inferiors
- References: <BANLkTikpEhjP-RPyLFcwoF=nC3K+oas-ZQ@mail.gmail.com> <BANLkTin1PTQ5vuO5h+eoAzkRgym0HCfCmw@mail.gmail.com>
On Wednesday 13 April 2011 14:33:01, Kevin Pouget wrote:
> Hello,
>
> I noticed a behavior which appears strange to me, I would like to know
> if it was expected:
>
> > (gdb) list
> > 1 int main() {
> > 2 fork() ;
> > 3 }
> >
> > (gdb) break 3
> > (gdb) set follow-fork-mode child
> > (gdb) run
> > ...
> > Breakpoint 1, main () at fork.c:3
> > 3 }
> > (gdb) info inferiors
> > Num Description Executable
> > * 2 process 26039 /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
> > 1 <null> /home/kevin/travail/arm/perso/root/sample/fork-threads/fork
>
> why are there two inferiors? I expected either to stay in inf 1 (if
> the pid of an inferior can change) or inf 1 to disappear, but not to
> keep both of them!
Hmm, if detach-on-fork is on (the default), yeah.
I'd argue for staying in inf 1. linux-nat.c:linux_child_follow_fork
is the place to look. The problem is the vfork case, and
what to do with the vfork parent.
--
Pedro Alves