https://bugzilla.kernel.org/show_bug.cgi?id=215769 Florian Weimer (fweimer@xxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fweimer@xxxxxxxxxx --- Comment #11 from Florian Weimer (fweimer@xxxxxxxxxx) --- (In reply to brauner from comment #10) > glibc does vfork() via inline assembly massaging. There's probably > atfork handlers and a bunch of other stuff involved so it's difficult to > do a remote diagnosis. glibc does not run fork handlers for vfork. > (And note that calling anything other than execve() or _exit() after > vfork() is basically undefined behavior.) Historically, glibc supports calling malloc after vfork, so that applications can implement their own form of close_range by reading /proc/self/fd. I wonder if we need to handle CLONE_NEWTIME in posix_spawn in some way. Surely that clone(CLONE_VM | CLONE_VFORK | SIGCHLD) call should fail as well if vfork is blocked after CLONE_NEWTIME, so CLONE_NEWTIME probably breaks posix_spawn. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
