Change:
panic_unwind = { path = "../panic_unwind", optional = true } panic_abort = { path = "../panic_abort" } core = { path = "../core" } <del> libc = { version = "0.2.85", default-features = false, features = ['rustc-dep-of-std'] } </del> <ins> libc = { version = "0.2.88", default-features = false, features = ['rustc-dep-of-std'] } </ins> compiler_builtins = { version = "0.1.39" } profiler_builtins = { path = "../profiler_builtins", optional = true } unwind = { path = "../unwind" }

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Starting with Android Oreo (8), Android started using a seccomp based filter approach to syscalls, explicitly allowing syscalls, see https://android- enumerates the allowed syscalls. This means, that dispatching a generic syscall mechanism as introduced with this PR will result in a panic. On top of that, I found that older versions of Android, such as Android 6, will return for this syscall. My tests showed that this only happens on x86, although I can't explain why. As there's no way to detect the target android API level, the safest way would probably be to always use the syscall, and remove the special handling of the syscall. This could also be just guarded for x86 -- but would be happy to get an explanation on why it's only on that architecture (see ). I have tested this with both real devices as well as Android emulators. I tried this code: and poked it with . I expected to see this happen: returns Instead, this happened: Android = 8.0: panic because of seccomp Android < 8.0: strace output Which translate to Function not implemented. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.48 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Is the x86 thing an emulator? From the strace output it would seem that an entirely wrong syscall is being invoked. Can this issue reproduce if you call from C? If so, consider reporting a bug against Android as well.

Happens both on an Emulator and a real x86 device (Zebra ET50). I will try to whip up a minimal reproducer using the socket4 API. Edit: This works fine on my linux machine, but running it on an Android API 23 x86 emulator yields: This also fails when using the generic syscall with errno 38: Seems my guess on why that started happening is wrong; now I wonder why that ever worked .. :confused: Just for reference:
and ping libs any insights to share about this?
Error: This team () cannot be pinged via this command; it may need to be to on the master branch. Please let know if you're having trouble with this bot.
Hmm, maybe this has something to do with it: I've never heard of the "socketcall syscall" before, but apparently, on x86 Linux (before 4.3), you have to call . A bit annoying, because there is no documentation on what args should be. It "points to a block containing the actual arguments". The Linux man page specifically says this: Linux 4.3 also the regular syscalls for x86, but that's not something we can rely on for the android target :( So I think there are two options: 1) Drop accept4 on Android and accept the race condition on the CLOEXEC flag. 2) Figure out how to use correctly for x86 Android in .
Note: although the same weird syscall is required for Linux < 4.3 (which is still a tier 1 platform), it shouldn't affect the Linux target because there rust libc is just calling . from the real libc.
It would be nice if Android's seccomp filter allowed the direct syscalls on x86 too, not just on arm; that'd be worth trying to get to Android. But in the meantime, it looks like Android targets on 32-bit x86 will need to invoke for all socket syscalls, rather than making the syscalls directly.
It may not be the seccomp filter though. Older x86 kernels really do not have the accept4 syscall. Anyway, I'm working on a PR for libc to switch to on x86 android.

PR opened:
thank you and
label -I-prioritize -E-needs-bisection
Note: back when accept4 was used on more platforms, std couldn't update to the latest libc. So it currently has the same workaround. I submitted to switch to so would also receive the fix (after a libc bump).
This isn't actually fixed yet, my bad for accidentally linking the issue. Might be good to re-open until it really is solved in std too.
no worries, I'll reopen it
Lmao, github needs to come up with better algorithm to decide when to close issues with keywords. could you reopen this issue ?
Since the PR is merged, and now uses , all that is left to fix this on the main branch is to have a version bump (and a matching bump of the dependency for ). Is that going to be on time for 1.49.0, or should someone be pinged to ask for a release?
Released libc 0.2.87, you can now update the dependency :)
Thanks! Opened :)