https://bugs.kde.org/show_bug.cgi?id=342040
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #2 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Steven Stewart-Gallus from comment #0)
> Typically, clone is used with the CLONE_VFORK | CLONE_VM options to emulate
> the vfork system call but with additional options. However, it is extremely
> awkward and dangerous to use vfork functionality in such a way that stacks
> are shared. To make things safer and avoid getting into trouble with
> compilers like Clang misoptimizing things I plan to use clone with
> CLONE_VFORK | CLONE_VM and not share stacks but jump to a newly allocated
> one. CLONE_VM alone without CLONE_VFORK is explicitly unsupported by
> Valgrind.
CLONE_VM without CLONE_VFORK is effectively unsupported.
However, the way valgrind "supports" CLONE_VM|CLONE_VFORK is to just
remove these 2 flags: valgrind does not support vfork semantic, and
so transforms a vfork into a fork, hoping the application does not
depends on the vfork semantic.
See the following code in e.g. syswrap-amd64-linux.c:
case VKI_CLONE_VFORK | VKI_CLONE_VM: /* vfork */
/* FALLTHROUGH - assume vfork == fork */
cloneflags &= ~(VKI_CLONE_VFORK | VKI_CLONE_VM);
case 0: /* plain fork */
...
That being said, it is unclear why SEGV is raised.
A simple fork test (none/tests/fork) gives the following strace -f valgrind:
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f15d396a9d0) = 18741
With your test program, strace -f valgrind gives:
clone(child_stack=0, flags=SIGCHLD) = 18774
So, I would guess that what causes the SEGV is not the child stack being 0,
as this looks 'classical' when vfork-ing or clone-ing under Valgrind,
but rather the CLEARTID/SETTID and child_tidptr aspects.
--
You are receiving this mail because:
You are watching all bug changes.
