| Issue |
173551
|
| Summary |
[lld] SIGABRT in ld.lld during mass parallel Android builds (NDK r29, tmpfs stress test)
|
| Labels |
lld
|
| Assignees |
|
| Reporter |
FLYCOM-E
|
Hi folks,
I think I've managed to stress-test ld.lld into submission. Or maybe I just found a real bug.
What happened:
I was running a mass Android compilation script(you know, the kind that builds 15 API levels × 4 archs × 3 languages = 180 combos) in a tmpfs for speed. After a while, ld.lld started throwing SIGABRTs like confetti. The weird part? It only happens under heavy parallel load, and seems related to tmpfs.
Crash details:
· Signal: SIGABRT (of course)
· Threads: 7 threads all showing stack corruption (see backtrace)
· Core dumps: Multiple core-ld.lld-* files generated (attached gdb output)
· Command that crashed:
```
/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/ld.lld -s -EL -z now -z relro -z max-page-size=4096 --use-android-relr-tags --pack-dyn-relocs=relr -X --hash-style=gnu --eh-frame-hdr -m armelf_linux_eabi -pie -dynamic-linker /system/bin/linker -o Module_Files/wipe_cache/StorageClean /opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib/arm-linux-androideabi/35/crtbegin_dynamic.o -L/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/lib/clang/21/lib/linux/arm -L/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib/arm-linux-androideabi/35 -L/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib/arm-linux-androideabi -L/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib/../lib -L/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib -llog /tmp/StorageClean-d9f7be.o /opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/lib/clang/21/lib/linux/libclang_rt.builtins-arm-android.a -l:libunwind.a -ldl -lc /opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/lib/clang/21/lib/linux/libclang_rt.builtins-arm-android.a -l:libunwind.a -ldl /opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/../sysroot/usr/lib/arm-linux-androideabi/35/crtend_android.o'
```
Yes, it's that long. Blame Android's build system.
Environment:
· NDK: r29 (from Google's official distribution)
· Host: Linux arm64, Ubuntu 25.x, 4GB RAM + 4GB swap
· Filesystem: tmpfs (because why not live dangerously?)
· Reproducibility: Intermittent under heavy load, but I got 3 crashes in 30 minutes
Minimal repro (maybe):
```bash
# Not exactly minimal, but this is what dies:
/opt/NDK_29/toolchains/llvm/prebuilt/linux-arm64/bin/ld.lld \
-s -EL -z now -z relro ......(more) \
-o Module_Files/wipe_cache/StorageClean \
-llog /tmp/StorageClean-d9f7be.o \
-l:libunwind.a -ldl -lc \
-l:libunwind.a -ldl # ← Wait, why is libunwind.a linked twice?
```
Observations:
1. The command links libunwind.a twice (not my doing - this is what NDK's toolchain generates)
2. Uses -llog (Android logging lib)
3. All crashes happen when linking different targets, but same pattern
4. Single-threaded builds seem OK (but who has time for that?)
Workaround that kinda works:
```bash
export LDFLAGS="-Wl,--threads=1" # Single-threaded linking
# or
export LDFLAGS="-fuse-ld=gold" # Use gold instead of lld
```
GDB backtrace:
```
#0 0x00000000034b38e8 in ?? ()
#1 0x00000000034c919c in ?? ()
#2 0x00000000034c7c98 in ?? ()
#3 0x00000000034c7c0c in ?? ()
#4 0x00000000034c8140 in ?? ()
#5 0x00000000034bd60c in ?? ()
#6 0x00000000034bd32c in ?? ()
#7 0x0000000003509140 in ?? ()
#8 0x0000000001522d98 in ?? ()
#9 0x00000000034bd05c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
```
My theory:
Either:
1. ld.lld's thread pool gets confused under memory pressure (tmpfs + many parallel links)
2. Something about handling duplicate -l:libunwind.a causes internal state corruption
3. NDK r29's lld just doesn't like being yelled at by 180 build jobs simultaneously
Can someone:
1. Confirm if the duplicate -l:libunwind.a is expected?
2. Check if there's a known issue with lld + tmpfs + high concurrency?
3. Or just tell me I'm abusing the toolchain too hard (fair enough)?
Full system info and core dump analysis attached. Thanks for looking!
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
