[GDB follow-fork] behavior change for wait()

[Marcel Moolenaar]

On Apr 29, 2012, at 9:43 AM, Konstantin Belousov wrote:

> On Fri, Apr 27, 2012 at 03:33:49PM -0700, Marcel Moolenaar wrote:
>> Hi Dmitry,
>> 
>> I've been testing the follow-fork changes in GDB and ran into some weird
>> behavior. Without gdb, my test program (attached) prints something like:
>> 
>> fbsdvm%	./fe 
>> fe(41042): initial process. Doing fork & exec...
>> fe(41043): child after fork. Doing exec...
>> fe(41043): child after exec. Exiting...
>> fe(41042): child 41043 exited with status 0
>> 
>> In particular: the parent (pid=41042) calls wait(2) to reap the child and
>> the child exits with 0.
>> 
>> Under gdb, I see this:
>> 
>> fbsdvm%	gdb ./fe
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "i386-marcel-freebsd"...
>> (gdb) br main
>> Breakpoint 1 at 0x80487b0: file fe.c, line 14.
>> (gdb) run
>> Starting program: /usr/home/marcel/fe 
>> 
>> Breakpoint 1, main (argc=Error accessing memory address 0x1: Bad address.
>> ) at fe.c:14
>> 14	{
>> (gdb) n
>> main (argc=1, argv=0xbfbfebb4) at fe.c:19
>> 19		if (getenv("__FE_FORKED__") != NULL) {
>> (gdb) c
>> Continuing.
>> fe(41141): initial process. Doing fork & exec...
>> [New process 41143]
>> fe(41143): child after fork. Doing exec...
>> fe(41143): child after exec. Exiting...
>> fe(41141): wait(2) failed with error 10 (No child processes)
>> 
>> Program exited normally.
>> (gdb) 
>> 
>> When stepping at least once, the inferior will not be able to properly wait(2)
>> for its child as it seems to have been reaped already. I suspect this is done
>> by the debugger -- unintentionally at least.
>> 
>> Have you seen this before?
> 
> How old is your kernel ? In particular, do you have
> r232048+r232104+r232947+r232975+r233808+r233809 ?

Yup:

fbsdvm%	uname -a
FreeBSD fbsdvm 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r234823: Sun Apr 29 16:18:07 PDT 2012     marcel at fbsdvm:/usr/obj/usr/src/sys/FBSDVM  i386

This is off of the projects/nand branch, BTW:
fbsdvm%	svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn+ssh://svn.freebsd.org/base/projects/nand
Repository Root: svn+ssh://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 234823
Node Kind: directory
Schedule: normal
Last Changed Author: gber
Last Changed Rev: 234550
Last Changed Date: 2012-04-21 10:48:17 -0700 (Sat, 21 Apr 2012)

Which is sync'd up to head @234446.

-- 
Marcel Moolenaar
marcel at xcllnt.net