https://bugs.kde.org/show_bug.cgi?id=342040
--- Comment #6 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Nach from comment #4) > 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. The above is normal. Valgrind does not keep the CLONE_VM flag, as there is no way to support this: valgrind has to do a lot of work in the child and with CLONE_VM, any work done on any Valgrind data structure would corrupt the parent Valgrind data structures. > > > 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. The fact that you see a NULL stack is also normal: this is the 'valgrind host stack'. The stack that you provide in the clone syscall is set as the guest stack (not visible in the syscall, this is only visible in the simulated CPU SP register). > 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. In the final version of the commited patch, CLONE_VFORK is kept. There is no way to support CLONE_VM. > > 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. Thanks for any additional testing or verification you could do. -- You are receiving this mail because: You are watching all bug changes.
