Description of problem: Bug 464520 describes a problem with the ptrace setoptions behavior on vfork. That bug is fixed in latest 2.6.27 kernels, but it reveals a different problem. The new behavior when ptraceing a vfork()ed child now retains the vfork() shared page semantics (semantics which POSIX says no one should expect :-). This is a non backward compatible change, the previous behavior of ptraceing across a vfork resulted in the vfork being treated as a fork, with the parent and child getting separate copies of memory pages. In a multi-process debugger (such as the one I work on all the time), this presents fantastic bookkeeping problems. Out of the blue, modifying one process will (behind the debugger's back) modify a different process at the same time. I concede the desirability of being able to ptrace across a vfork without changing the semantics of a non-ptraced vfork, but there are advantages the other way as well, and since it has always worked the other way, I maintain it should continue to work the other way (i.e. as through it were a fork, not a vfork). If you want to support the new semantics, it seem like the proper way to do it would be by adding something like PTRACE_O_VFORKSHARESPAGES so people needing the new semantics can explicitly request it rather than having it unexpectedly thrust upon them. Version-Release number of selected component (if applicable): 2.6.27-3.fc10 How reproducible: every time Steps to Reproduce: 1. I can produce a test program if anyone really needs one. 2. 3. Actual results: shared memory between parent and child across a ptrace Expected results: original behavior of vfork being treated as fork Additional info:
The description is inaccurate AFAIK. Please produce a test program that demonstrates on some past vanilla kernel where PTRACE_O_TRACEVFORK changed the meaning of vfork.
Yikes! Sorry about the noise. I did write a test program, but it always says memory is indeed shared on all the fedora and rhel kernels I've tried. I've definitely seen the non-shared behavior, but I guess that was only with some custom kernels, so turning vfork into fork must be something we did either accidentally or deliberately. I guess I need to poke around some more and clear up my confusion about which kernels this happens on.
The strace utility does tweak vfork syscalls to be fork syscalls. Maybe that's what you were thinking of.