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

[Marcel Moolenaar]

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?

-- 
Marcel Moolenaar
marcel at xcllnt.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fe.c
Type: application/octet-stream
Size: 1165 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20120427/47821f62/fe.obj