Help wanted: segfault in Android stdlib tests - default plan to disable tests on Android

Following on from Help wanted to debug a segfault in a standard library test on Android, we're still seeing regular failures in CI due to this issue and it appears to be significantly worse on GitHub Actions (which we're evaluating at the moment).

We see three options, in order of desirability:

  1. the issue is fixed
  2. we disable should_panic tests on android
  3. we disable Android tests entirely (note that Android is a tier 2 platform so 'shouldn't' be getting testing anyway!)

The current status of things is:

  • the infra team is extremely unlikely to be able to pursue option 1 or 2, hence 3 is the default (as sad as it is)
  • the issue appears to be related to should_panic tests (hence option 2 above)
  • to disable should_panic tests, we don't want to scatter cfgs everywhere, so two things need to happen:
    • shows roughly what needs to happen to disable normal should_panic tests (though that specific PR didn't work so may be misleading :sweat_smile:)
    • rustdoc needs altering to allow us to pass a flag to disable should_panic doctests

The timeline for this is around a month - at that point we're expecting to make the final decision on GitHub Actions, which acts as a motivation to solve this issue one way or another.


We have at least 2 teams in Mozilla that rely on Rust on Android, so obviously we are interested in that platform being tested and actually working. I'll try to see if we can allocate some time and effort on this.


I've narrowed down the issue to a bug in Android's dlmalloc. See this comment for a more detailed analysis.

The solution is to disable the try_reserve tests that make large allocations (a bit above 2GB).


Thanks! I didn't find time to look into this, so I'm more than happy you and Aaron did.

I wonder if a long-term solution would be to also upgrade the Android version Rust targets? As I understand this might be a solved thing in more recent Android as well.

What version of Android do we currently use as a target?

According to this comment it's API level 9 and as mati865 said: "API level 9 means Android 2.3-2.3.3 released 9 years ago which seems overly conservative."

Looking further this actually upgraded to level 14, shipped in Rust 1.23.0.

mati also mentioned: "From what I could find posix_memalign was added by API level 16 which is Android 4.1.x released almost 8 years ago."

We could make that jump, if it actually fixes problems, or go even further until Android 5 (that's kinda what we currently need to support)

Going by , I think upgrading to 4.1.x seems completely reasonable.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.