https://bugs.kde.org/show_bug.cgi?id=384732
--- Comment #6 from Mark Wielaard <m...@klomp.org> --- (In reply to Tom Hughes from comment #5) > We already detect CLONE_VFORK|CLONE_VM as a special case and deliberately > drop CLONE_VM because I imagine anything else would be a disaster as > valgrind's shadow memory etc would be shared. Sharing shadow memory should be fine since we do share the actual memory. But sharing the thread state is probably a problem. And indeed just not dropping VM_CLONE when we see VM_VFORK doesn't work. It does successfully create the child and execs the new process, but returning to the parent seg faults fairly soon. > The comments in the source explicitly mention preserving CLONE_VFORK to > preserve the wait-for-exec semantics and that does indeed seem to work. Earlier we did drop both CLONE_VFORK and CLONE_VM. And I can definitely see why CLONE_VM is bad without CLONE_VFORK. I am probable missing some bad sharing which messes things up. But I still wonder if we could handle CLONE_VFORK | CLONE_VM specially as if it was a simple thread creation (do_clone vs do_fork_clone) up till the actual exec/exit call (at which point we might have to do some magic to do the actual fork). Maybe too much bad voodoo though... -- You are receiving this mail because: You are watching all bug changes.
