about summary refs log tree commit diff
path: root/src/test/ui/process/process-panic-after-fork.rs
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-197/+0
2022-12-09Fix process-panic-after-fork.rs to pass on newer versions of Android.Peter Collingbourne-36/+41
The test process-panic-after-fork.rs was checking that abort() resulted in SIGSEGV on Android. This non-standard behavior was fixed back in 2013, so let's fix the test to also accept the standard behavior on Android.
2022-10-07Ensure the correct tombstone file is openedFlorian Bartels-11/+11
2022-10-06Ensure crash is caused by libc::abortFlorian Bartels-4/+22
2022-10-06Fix whitespaceFlorian Bartels-1/+3
2022-10-06Fix test for AndroidFlorian Bartels-0/+22
2022-10-06Enable test on AndroidFlorian Bartels-1/+0
2022-10-03Ignore fuchsia on two compiler testsAndrew Pollack-0/+1
2022-09-27Stabilize bench_black_boxUrgau-1/+0
2021-11-05Revert "Do not call getpid wrapper after fork in tests"Josh Stone-16/+1
This reverts commit 12fbabd27f700a59d0e7031f0839b220c3514bcb. It was only needed because of using raw `clone3` instead of `fork`, but we only do that now when a pidfd is requested.
2021-08-01Do not call getpid wrapper after fork in testsDominik Stolz-1/+16
The test calls libc::getpid() in the pre_exec hook and asserts that the returned value is different from the PID of the parent. However, libc::getpid() returns the wrong value. Before version 2.25, glibc caches the PID of the current process with the goal of avoiding additional syscalls. The cached value is only updated when the wrapper functions for fork or clone are called. In PR #81825 we switch to directly using the clone3 syscall. Thus, the cache is not updated and getpid returns the PID of the parent. source: https://man7.org/linux/man-pages/man2/getpid.2.html#NOTES
2021-05-14panic abort after fork test: Disable on androidIan Jackson-0/+1
And link to the issue. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-13Tolerate SIGTRAP for panic abort after panic::always_abortIan Jackson-1/+1
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort! See eg https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765 This is probably a bug, but we don't want to entangle this MR with it. When it's fixed, this commit should be reverted. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-13Use SIGUSR1 rather than SIGTRAP for "allocated after fork"Ian Jackson-2/+2
Some platforma (eg ARM64) apparently generate SIGTRAP for panic abort! See eg https://github.com/rust-lang/rust/pull/81858#issuecomment-840702765 This is probably a bug, but (i) we want to avoid that bug rather than trying to fix it now and (ii) it would better to use a signal that is less at risk of strangeness. I grepped the rust-lang/rut codebase for SIGUSR and there were no hits. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-05-07panic ui test: Provide comprehensive test for panic after forkIan Jackson-0/+150
This tests that we can indeed safely panic after fork, both a raw libc::fork and in a Command pre_exec hook. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 12:17:03 +0000