Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process spawning in libnative does not account for unrecoverable execve failures #13874

Closed
mstewartgallus opened this issue May 1, 2014 · 3 comments

Comments

@mstewartgallus
Copy link
Contributor

Sometimes when execve fails it doesn't return with an error. Quoting from the blog EWONTFIX here:

For common reasons it might fail, the execve syscall returns failure in the original process image, allowing the program to handle the error. However, failure of execve is not entirely atomic:

The kernel may fail setting up the VM for the new process image after the original VM has already been destroyed; the main situation under which this would happen is resource exhaustion.

Even after the kernel successfully sets up the new VM and transfers execution to the new process image, it's possible to have failures prior to the transfer of control to the actual application program. This could happen in the dynamic linker (resource exhaustion or other transient failures mapping required libraries or loading configuration files) or libc startup code. Using musl libc with static linking or even dynamic linking with no additional libraries eliminates these failure cases, but systemd is intended to be used with glibc.

This means that using a pipe to report errors is incorrect or at least does not cover all cases.

My personal hack to get around the issue is here.

In order to check for execve aborts I wait for exits or stops and arrange for a stop signal to be delivered atomically after execve and then continue. Currently, in my own code I do not actually check for the specific exit status that is generated when execve aborts but that will be easy to add in later.

@thestinger
Copy link
Contributor

We abort on out-of-memory conditions everywhere else, so adding hacks to handle it here seems a bit weird.

@alexcrichton
Copy link
Member

What is the behavior that you are expecting? The current behavior would be to report a successful spawn (which is arguably true if the kernel tore down the original VM), and then wait() will return an error.

Is that not what you are expecting?

@mstewartgallus
Copy link
Contributor Author

Ugh, yes I'm wrong, the pipe will give a short read and fail. I really shouldn't have posted a bug late at night.

arcnmx pushed a commit to arcnmx/rust that referenced this issue Jan 9, 2023
…, r=Veykril

fix: keep whitespace in extract function handler

Fixed rust-lang#13874
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants