On Unix-like OSes, std::process::Command::spawn() should not use assert! from the child process after fork()

On Unix-like OSes, std::process::Command::spawn() uses an assert! to check if the pipe I/O succeeded. If that assert! fails, it will call panic!, which is not signal-safe. It's better to use if ....is_err() { std::intrinsics::abort() } there.
libc::abort() (std::process::abort()) shouldn't be used as a replacement, as, at least in glibc, it's not signal-safe^[1][2], although all of the C standard, the C++ standard, the POSIX standard, and Linux man-pages say it should be.

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=df98782dd7ea6c1476184a365bd9f3954f481a18;hb=refs/heads/master#l54
[2] https://www.gnu.org/software/libc/manual/html_node/Aborting-a-Program.html#Aborting-a-Program

It seems that nobody is aware of this... I know many libraries (such as the glibc above) don't care about signal safety in such situation. If you're not aware of this, feel free to close this issue.

Closing as there is no response.

[mati865]

cc @joshtriplett

[joshtriplett]

This is a good catch. We certainly try to be signal-safe in such contexts, and failing to do so is a bug. Sorry to see that this didn't get a response. I'm reopening this, as it remains a bug.

I discovered that if libc::abort() is not signal-safe (in glibc), then rtabort!() is not signal-safe, so the signal handlers in the standard library that call rtabort!() is actually not signal-safe:

rust/src/libstd/sys/unix/stack_overflow.rs

Lines 92 to 106 in 891e6fe

	unsafe extern "C" fn signal_handler(
	signum: libc::c_int,
	info: *mut libc::siginfo_t,
	_data: *mut libc::c_void,
	) {
	use crate::sys_common::util::report_overflow;
	let guard = thread_info::stack_guard().unwrap_or(0..0);
	let addr = siginfo_si_addr(info);
	// If the faulting address is within the guard page, then we print a
	// message saying so and abort.
	if guard.start <= addr && addr < guard.end {
	report_overflow();
	rtabort!("stack overflow");

Maybe I should open a new issue or report the abort(3) bug to glibc...

[joshtriplett]

On Mon, Jul 20, 2020 at 01:32:22AM -0700, hyd-dev wrote: I just realized if `libc::abort()` is not signal-safe (in glibc), then `rtabort!()` is not signal-safe, so the signal handlers in the standard library that call `rtabort!()` is actually not signal-safe: https://github.com/rust-lang/rust/blob/891e6fee572009ff2be4d4057fb33483610c36a7/src/libstd/sys/unix/stack_overflow.rs#L92-L106 Maybe I should open a new issue or report the `abort(3)` bug to glibc.

`signal-safety(7)` lists `abort(3)` as async-signal-safe. If it isn't in practice async-signal-safe in glibc, that's a bug and you should report it.

On Mon, Jul 20, 2020 at 01:32:22AM -0700, hyd-dev wrote:
I just realized if libc::abort() is not signal-safe (in glibc), then rtabort!() is not signal-safe, so the signal handlers in the standard library that call rtabort!() is actually not signal-safe:

rust/src/libstd/sys/unix/stack_overflow.rs

Lines 92 to 106 in 891e6fe

	unsafe extern "C" fn signal_handler(
	signum: libc::c_int,
	info: *mut libc::siginfo_t,
	_data: *mut libc::c_void,
	) {
	use crate::sys_common::util::report_overflow;
	let guard = thread_info::stack_guard().unwrap_or(0..0);
	let addr = siginfo_si_addr(info);
	// If the faulting address is within the guard page, then we print a
	// message saying so and abort.
	if guard.start <= addr && addr < guard.end {
	report_overflow();
	rtabort!("stack overflow");

Maybe I should open a new issue or report the abort(3) bug to glibc.

signal-safety(7) lists abort(3) as async-signal-safe. If it isn't in practice async-signal-safe in glibc, that's a bug and you should report it.

Reported as https://sourceware.org/bugzilla/show_bug.cgi?id=26275.

So I think libc::abort() can be used, and if ... { something_like_rtabort!() } is suitable as a replacement. WDYT?

So I think libc::abort() can be used, and if ... { something_like_rtabort!() } is suitable as a replacement. WDYT?

@joshtriplett Should this be fixed like that?

[joshtriplett]

Given the above research, I don't think libc::abort() is safe to use either.