https://bugs.kde.org/show_bug.cgi?id=342040
--- Comment #4 from Nach <nac...@gmail.com> --- Hello Philippe, I double checked with Valgrind 3.12.0 to ensure the bug was still occuring (it was), and then applied your patch. The basic code I was testing no longer crashes and seems to be mostly working as it should with your patch! Strace now shows: clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f8e5944d9d0) = 16514 Which I'm not sure what to make of. Anyways, I'm setting a seperate stack to use, and some basic testing shows things are behaving sanely, although I'm not certain the stack I'm specifying is even being used. Of the flags, CLONE_VM|CLONE_VFORK|SIGCHLD, SIGCHLD is indeed being delivered to the parent, and the child appears to be scheduled before the parent (at least when tested across a bunch of runs), although the memory is not being shared, so it would appear CLONE_VM is being ignored. For the needs of a well implemented posix_spawn() such as in musl or mine, CLONE_VM and CLONE_VFORK are really just optimizations, so it matters little if either was not respected. The main issue is to ensure a seperate stack is in operation in the child in order to not mangle the parent's, and preliminary testing shows it now appears to be fine. I'll do further testing with more complicated cases (heavier stack use in child) to ensure whatever clone mangling is done seems to work for these scenerios. However, if a library/application is actually expecting the shared memory semantics, it seems a little more work is required. -- You are receiving this mail because: You are watching all bug changes.
