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 mar...@xcllnt.net
fe.c
Description: Binary data
_______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"