time-related problems with powerpc64le linux_raw support

[decathorpe]

It's me again :) After expanding the architectures I ran the rustix test suite for, I found another architecture-specific failure in the test suite. This time, it looks like the - relatively new - linux_raw support for powerpc64le still has some problems.

In particular, the time tests seem to be problematic, in not obviously deterministic ways, but always with an assertion failure. Looks like the powerpc64le machine I have access to doesn't necessarily behave as the code expects (line number is from rustix 0.33.6, but according to the commit history, this part of the code has not been changed since, as far as I can tell).

thread '<foo>' panicked at 'assertion failed: !ptr.is_null()', src/imp/linux_raw/vdso_wrappers.rs:375:13

What's weird is that the test that failed changed, depending on which tests I skipped:

• first, all tests from tests/time passed, except dynamic_clocks::test_conditional_clocks
• second, I added --skip test_conditional_clocks to cargo test --, and then dynamic_clocks::test_dynamic_clocks failed instead
• third, I did --skip dynamic_clocks, but then monotonic::test_monotonic_clock failed instead
• last, I did both --skip dynamic_clocks and --skip test_monotonic_clock, at which point no new test failures occurred

Since actual failing test depended on which other tests were running (or not), this looks like some "hidden shared global state" to me ... or it's just a Heisenbug :)

Possibly relevant environment info:

• Fedora Rawhide, 36, 35, 34 on powerpc64le
• running on Linux 5.16.18 host
• Rust / Cargo 1.60.0 stable

[sunfishcode]

Thanks for the report! I've now submitted #286 which I expect will fix the problem.

The apparent hidden shared state is coming from the fact that rustix does vdso initialization for the whole program once, in the first thread that needs it. While that initialization is running, other threads use a fallback which is slower but always works. So whichever test thread gets to the initialization first hits the assert, and the rest of the tests end up using the fallback and pass.

[decathorpe]

Thanks for the investigation, and the quick fix! I'll try applying the linked patch to my local build for Fedora.

PS: It's not often that my (most often, kinda obscure) bug reports for Rust projects get this kind of attention and quick responses with proposed fixes. Thank you 🍻

[sunfishcode]

This is now released in v0.33.7 and v0.34.4. Thanks for confirming the fix!