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.

Reply via email to