This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/22273] Improper assert in Linux posix_spawn implementation

--- Comment #5 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Adhemerval Zanella from comment #3)
> > However I do not think setting the err atomically would help here, ideally
> > we will need kernel help on to signaling abrupt child execution. One option
> > would be to set all signals to SIG_IGN (although it won't help with SIGKILL
> > or SIGSTOP).
> I think atomic accesses are needed for their compiler barrier properties.

But exactly what you are trying to prevent in spawni code? Essentially the code
runs sequentially and I think it would not be legal the compiler evaluate ec
without checking for new_pid result.

> > What about removing the assert and setting all signal handler as SIG_IGN?
> We can't do that because the signal handler disposition is inherited across
> execve.  I think it is sufficient to check the waitpid status in combination
> with the error code.  I don't think we need to report whether the subprocess
> was terminated before or after the execve (which can be successful or not).

Right, we need to respect POSIX_SPAWN_SETSIGDEF.  What about:

diff --git a/sysdeps/unix/sysv/linux/spawni.c
index dea1650..f02ac19 100644
--- a/sysdeps/unix/sysv/linux/spawni.c
+++ b/sysdeps/unix/sysv/linux/spawni.c
@@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
   if (new_pid > 0)
       ec = args.err;
-      assert (ec >= 0);
       if (ec != 0)
-         __waitpid (new_pid, NULL, 0);
+       {
+         /* It handles the unlikely case where the auxiliary vfork process
+            is killed before calling _exit or execve.  */
+         int status;
+         __waitpid (new_pid, &status, 0);
+         if (WIFSIGNALED (status))
+           ec = -1;
+       }
     ec = -new_pid;

It should handle a installed signal handler not erased by POSIX_SPAWN_SETSIGDEF
(assuming it won't terminate the process) and the case of of a termination
signal before _exit or execve.

You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]