Panics when /proc is not available on i386 about rustix HOT 5 CLOSED

rustix has some alternate strategies for obtaining the auxv recoreds.

• If you enable the "use-libc-auxv" feature (which is normally enabled by default), rustix calls the libc getauxval function instead of opening /proc/self/auxv. Because libc is also in control of program startup, libc implementations are able to read the auxv records from the stack instead of using /proc/self/auxv.
• If you have Linux >= 6.4 and enable the "alloc" feature, rustix will use Linux's new PR_GET_AUXV feature instead of opening /proc/self/auxv.

I have tended to assume rustix's various default-features = false configurations aren't of interest and would be a distraction for most users, and that it's sufficient to document them in comments in the code rather than the README, but I'm open to ideas. Perhaps a new AdvancedOptions.md file would make sense?

from rustix.

Thanks!

which is normally enabled by default

I see! I will ask async-io if they disabled it intentionally. I guess that's the most likely pitfall for users of rustix then.

from rustix.

I've disabled this feature in async-io intentionally, as async-io does not require the libc auxiliary vector to function normally. I do not want to make async-io restrictive in this regard. Therefore the intended solution is to enable the libc auxv in the downstream consumer.

from rustix.

I expect this is fixed by #979, which makes rustix (a) try a little harder to use PR_GET_AUXV even when "alloc" isn't set, but also (b) fall back to int 0x80, so that it always at least works, even if it's slower. Most users still probably want "use-libc-auxv", which is carefully written to avoid pulling in the libc crate.

from rustix.

I believe this is fixed in #979, which is released in rustix 0.38.29. If there are any further issues, please reopen or file a new issue!

from rustix.