As reported on hackers@ and met with a hail if silence :-) http://docs.freebsd.org/cgi/getmsg.cgi?fetch=80369+0+current/freebsd-hackers kern_exit.c:wait1() has the following lines in -STABLE: > if ((p->p_sigparent != SIGCHLD) ^ ((uap->options & WLINUXCLONE)!= 0)) > continue; As it is, if you ptrace(PT_ATTACH) to a process started with rfork(flags|RFLINUXTHPN), and do a waitpid() as you normally would, this causes waitpid() to fail with ECHILD, because the original parent/child relationship doesn't hold, and the debugger doesn't know that the debugee was started with RFLINUXTHPN. This can also mean that the ptrace(PT_DETACH) ends up killing the process, because you can't guarantee that it is stopped by the time you get to do the ptrace(PT_DETACH). In order to allow existing ptrace(2)-using programs to attach to such processes, would the following be more appropriate? > if ((p->p_sigparent != SIGCHILD && (p->p_flag & P_TRACED) == 0) ^ > ((uap->options & WLINUXCLONE) != 0)) (BTW: Why "^" rather than "!=" ? I would have thought a boolean operator more natural here.) Cheers, Peter. Fix: This fixes it locally. RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/kern/kern_exit.c,v retrieving revision 1.92.2.10 How-To-Repeat: Try attaching to a process started with rfork(RFLINUXTHPN) with gdb.
Responsible Changed From-To: freebsd-bugs->emulation One for the emulation team
State Changed From-To: open->feedback Is this still a problem with a recent FreeBSD?
State Changed From-To: feedback->open Back to "open", maybe an upcomming SoC student is willing to have a look at this.