Code change:
fn expect_aborted(status: ExitStatus) { dbg!(status); let signal = status.signal().expect("expected child process to die of signal"); <ins> #[cfg(not(target_os = "android"))] </ins> assert!(signal == libc::SIGABRT || signal == libc::SIGILL || signal == libc::SIGTRAP); <ins> #[cfg(target_os = "android")] { // Android signals an abort() call with SIGSEGV at address 0xdeadbaad // See e.g. https://groups.google.com/g/android-ndk/c/laW1CJc7Icc assert!(signal == libc::SIGSEGV); // Additional checks performed: // 1. Find last tombstone (similar to coredump but in text format) from the //    same executable (path) as we are (must be because of usage of fork): //    This ensures that we look into the correct tombstone. // 2. Cause of crash is a SIGSEGV with address 0xdeadbaad. // 3. libc::abort call is in one of top two functions on callstack. // The last two steps distinguish between a normal SIGSEGV and one caused // by libc::abort. let this_exe = std::env::current_exe().unwrap().into_os_string().into_string().unwrap(); let exe_string = format!(">>> {this_exe} <<<"); let tombstone = (0..100) .map(|n| format!("/data/tombstones/tombstone_{n:02}")) .filter(|f| std::path::Path::new(&f).exists()) .map(|f| std::fs::read_to_string(&f).expect("Cannot read tombstone file")) .filter(|f| f.contains(&exe_string)) .last() .expect("no tombstone found"); println!("Content of tombstone:n{tombstone}"); assert!( tombstone.contains("signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad") ); let abort_on_top = tombstone .lines() .skip_while(|l| !l.contains("backtrace:")) .skip(1) .take_while(|l| l.starts_with("    #")) .take(2) .any(|f| f.contains("/system/lib/libc.so (abort")); assert!(abort_on_top); } </ins> } fn main() {

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I am trying to fix it so that Rust's stdlib prevents unwinding, or allocating, in the child, after a fork on Unix (including in ). That is . (Allocation after fork of a multithreaded program is UB in several libcs.) I a new test case, Unfortunately this test fails, but just on Android: I have few good theories as to why. I wrote some speculations: I think this probably needs attention from an Android expert to try to repro and fix this issue. I suspect it's a problem with the library rather than the tests. The worst case is that it might be a general UB bug in Android Rust programs using or . I'm filing this issue here to try to ask for help again, since writing in doesn't seem like a particularly good way of getting the attention of Android folks. If we can't get a resolution, reluctantly, I guess I will disable that test on Android so that my MR can go through. The current situation is quite a hazard (see eg "panic! in Command child forked from non-main thread results in exit status 0") I will try to explain what the test does and what the symptoms seem to mean: The test file has a custom global allocator, whose purpose is to spot allocations in the child after fork. That global allocator has an atomic variable which is supposed to contain either zero (initially, meaning it's not engaged yet) or the process's pid. Whenever an allocator method is called, we read the atomic and, if it is not zero, we check it against . If it doesn't match we <strike</strike. The test enters , and engages the stunt allocator, recording the program's pid. Each call to (which is called from and therefore from ) produces output from . We see only one of these, so this must be the first test, . The test uses to fork. In the child, it calls (my new function to disable panic unwinding). It then panics (using the provided closure). This ought to result in the program dying with (or maybe or ). The parent collects the child's exit status. For the first test case, we run .