https://bugs.kde.org/show_bug.cgi?id=342040
--- Comment #7 from Nach <nac...@gmail.com> --- I ran a bunch more tests to ensure stability with the stack in the child. It's not using the exact stack the parent is specifying to use (beyond setting some a few bytes at the top of it), which may or may not be a problem for some (application which save child state?). However I can confirm that the stack in the child is as big as it needs to be. The larger the stack I tell clone() to use, the larger the stack appears to be in the child (which without would stack overflow). So it would seem any sane application using clone() with a stack which doesn't care about actually getting the stack data directly in the parent seems to work as expected. On very large stacks I did see this warning: ==8967== Warning: client switching stacks? SP change: 0xa5fd030 --> 0x65fd020 ==8967== to suppress, use: --max-stackframe=67108880 or greater But again, things work as expected. So all my testing shows this patch is good except it does not add support for more advanced cases (CLONE_VM, child stack access in parent). I cannot speak for the original bug reporter, but for the cases I'm dealing with, I consider this bug fixed. -- You are receiving this mail because: You are watching all bug changes.
