Summary
On an Android x86_64 target, the inet_gethost helper from the bundled OTP
runtime aborts under Android's FORTIFY runtime check:
inet_gethost[<pid>]: WARNING:Unable to write to child process.
FORTIFY: FD_SET: file descriptor 28872 >= FD_SETSIZE 1024
F DEBUG : Cmdline: /data/.../files/otp/erts-17.0/bin/inet_gethost 4
F DEBUG : pid: <pid>, name: inet_gethost
F DEBUG : #03 pc ... /data/app/.../lib/x86_64/libinet_gethost.so
inet_gethost calls FD_SET(fd, ...) with an fd (28872 in this run) that
exceeds FD_SETSIZE (1024). Android's FORTIFY (_FORTIFY_SOURCE) turns the
out-of-range FD_SET into a SIGABRT.
Impact
Non-fatal — the BEAM and the app keep running (the helper is re-spawned), but
name resolution routed through inet_gethost fails/retries and the helper
crashes repeatedly. Observed during normal startup, right after the app came up
and dialed its backend.
Environment
- ABI: x86_64 (Android 13, running under Waydroid on Linux)
- OTP runtime:
otp-android-x86_64-5c9c69fc, erts-17.0
libinet_gethost.so from the app's lib/x86_64/
Likely cause
inet_gethost (erts) uses select() / FD_SET on its inherited communication
fd. On Android, app processes routinely hold very high fd numbers, so the
inherited fd can exceed FD_SETSIZE (1024) and overflow fd_set. This is an
erts-level concern (inet_gethost.c) and could in principle affect any Android
ABI where the helper inherits a high fd — x86_64 just made it reproducible here.
Possible directions:
- build/patch the bundled erts
inet_gethost to use poll() instead of
select() / FD_SET (discussed upstream in OTP), or
- dup the helper's communication fd below
FD_SETSIZE before it runs.
Repro
- Build + deploy a mob app for
x86_64 (mix mob.deploy --native, abiFilters
including x86_64).
- Launch on an x86_64 Android target (e.g. Waydroid).
- Watch logcat (
BEAMout / inet_gethost / DEBUG) during startup — the
FORTIFY abort fires when a hostname lookup is routed through the helper.
Observed while standing up an x86_64 Waydroid CI target. Happy to attach a full
erl_crash.dump / logcat if useful.
Summary
On an Android x86_64 target, the
inet_gethosthelper from the bundled OTPruntime aborts under Android's FORTIFY runtime check:
inet_gethostcallsFD_SET(fd, ...)with an fd (28872 in this run) thatexceeds
FD_SETSIZE(1024). Android's FORTIFY (_FORTIFY_SOURCE) turns theout-of-range
FD_SETinto aSIGABRT.Impact
Non-fatal — the BEAM and the app keep running (the helper is re-spawned), but
name resolution routed through
inet_gethostfails/retries and the helpercrashes repeatedly. Observed during normal startup, right after the app came up
and dialed its backend.
Environment
otp-android-x86_64-5c9c69fc,erts-17.0libinet_gethost.sofrom the app'slib/x86_64/Likely cause
inet_gethost(erts) usesselect()/FD_SETon its inherited communicationfd. On Android, app processes routinely hold very high fd numbers, so the
inherited fd can exceed
FD_SETSIZE(1024) and overflowfd_set. This is anerts-level concern (
inet_gethost.c) and could in principle affect any AndroidABI where the helper inherits a high fd — x86_64 just made it reproducible here.
Possible directions:
inet_gethostto usepoll()instead ofselect()/FD_SET(discussed upstream in OTP), orFD_SETSIZEbefore it runs.Repro
x86_64(mix mob.deploy --native, abiFiltersincluding
x86_64).BEAMout/inet_gethost/DEBUG) during startup — theFORTIFY abort fires when a hostname lookup is routed through the helper.
Observed while standing up an x86_64 Waydroid CI target. Happy to attach a full
erl_crash.dump/ logcat if useful.