In the last 4 months, the liballoc test suite on the Android CI experienced occasional segmentation fault (signal 11), causing bors to bail out spuriously. This is tracked as issue #55861.
So far this is one of the most frequent unsolved spurious failure in 2019, and is happening once every three days on average (14 counts up to today).
We have yet no idea which of the liballoc tests causes the segfault. There is no core dump to inspect the stack trace. We’re reluctant to disable the entire liballoc test on Android even if it’s a Tier-2 platform, as a segfault indicates there’s really a memory safety bug hidden somewhere (the standard library or Android itself).
We’d like help from anyone who has idea on debugging or fixing this issue. Thanks!
@Aaron1011 narrowed down the problem to most likely being related to test panics/should_panic tests.
We discussed this in the infra team meeting today and decided that we would disable the should_panic tests on Android. This’ll basically be a #[cfg(not(target_os = "android"))] gate on each of those tests. Note that android is a tier-2 platform so we (the Rust team) ourselves don’t plan to invest time in fixing it, but if someone wants to attempt to narrow this down further we’ll gladly review patches.