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: This extracts the signal number from it and checks that it is as expected. On other systems this works. In the failing test, this test fails. The assertion on fails. Meaning, the child did die of a signal but the signal number wasn't the one expected. The previous debug print shows that the raw wait status (confusingly described by Rust stdlib as an "exit status") is <strike</strike. Usually, a bare number like that in a wait status is a signal number, and indeed that seems to be the case here since is . On Linux (and most Unices), is and 10 is . Ie, it seems that the child tried to allocate memory, despite my efforts to make sure that panicking does not involve allocation. Weirdly, a more-portable test case which uses and does not insist on specific signal numbers passes. It's definitely my stunt allocator which is tripping here, because when I changed it to use instead of , the failing test case signal number changed too.
modify labels +O-android +T-libs-impl
<strike provided an explanation here I still think there is a bug here but it is not Android-specific. I have a WIP branch to try to address it, so I think it's probably best if I close this issue and submit that as an MR when it's ready.</strike
My first guesses were right. In where I changed the stunt allocator to use , we see this:
I found a memory allocation with a patched Miri: With this code:
Apparently, the thread locals aren't working as expected. I think the child after fork is being treated as a new thread, and then the thread local storage has to be re-created. I think the surviving thread in the fork should inherit all the thread-locals from the forking thread in the parent.
But I just tested the code after , so there's no "new thread" or "parent" here...
Oh! Yes. You are right. Evidently the first use of this thread-local allocates. Presumably that would happen on a new thread as well as on the initial thread. Having panic rely on thread-locals, and thread-locals rely on the allocator, seems unfortunate. Having panic allocate is not good, especially when actually it's just trying to abort precisely to avoid this.