Summary
On Linux / aarch64, the codegraph-server binary segfaults deterministically at process startup — every invocation, including codegraph-server --version and --help, which do no real work. The crash is before main(), in a shared library's C++ static-initialization path. Built from source at v0.19.0-7-g06bcc88 (cargo build --release -p codegraph-server).
It is not environment-specific
I reproduced the identical crash with the binary built on two different toolchains, to rule out a bleeding-edge-distro issue:
| Build+run env |
gcc |
glibc |
Result |
| Ubuntu 25.10 (arm64) |
15.2 |
2.43 |
SIGSEGV at startup |
| Debian bookworm (arm64) |
12 |
2.36 |
SIGSEGV at startup |
A trivial hello-world Rust binary built on the same images runs fine, so the toolchains themselves are healthy.
Symptom / gdb
$ codegraph-server --version
Segmentation fault (core dumped) # ~0.1s, rc=139
# gdb: crash before main(), corrupt/unwindable stack
Program received signal SIGSEGV
=> 0x…: strb w19, [x0] # store byte through a pointer loaded from a global
# x0 = garbage (e.g. 0xaaaad51d1a0e); instruction sequence:
# adrp x0, <page>; ldr x0, [x0, #off]; strb w19, [x0] (w19 = 1)
# faulting PC is inside a shared lib (libc/libstdc++ region), symbols unavailable
Only ld-linux, libstdc++, libgcc_s, libm, libc are mapped at crash time (ONNX Runtime .so is not loaded for --version).
Ruled out
- ONNX Runtime — crashes identically whether
ort is statically linked (default) or dynamic (fastembed → ort-load-dynamic); the .so isn't even loaded at --version.
- Static-TLS overflow — TLS
MemSiz is ~2KB; bumping GLIBC_TUNABLES=glibc.rtld.optional_static_tls doesn't help.
- OOM — deterministic, same point every time; not memory-pressure-dependent.
- Stack overflow —
ulimit -s unlimited doesn't help.
- Environment — crashes under
env -i too.
Build notes (in case relevant)
RocksDB (librocksdb-sys 0.16 / RocksDB 8.10) needs CXXFLAGS="-include cstdint" to compile under gcc ≥13; unrelated to the crash but required to build at all on modern toolchains.
Ask
Is codegraph-server expected to work on Linux/aarch64 at this version? Happy to provide a full core dump, LD_DEBUG output, or test a patch. The pre-main store-through-a-bad-global-pointer suggests a static-initializer / relocation issue in a bundled C/C++ dependency.
Summary
On Linux / aarch64, the
codegraph-serverbinary segfaults deterministically at process startup — every invocation, includingcodegraph-server --versionand--help, which do no real work. The crash is beforemain(), in a shared library's C++ static-initialization path. Built from source atv0.19.0-7-g06bcc88(cargo build --release -p codegraph-server).It is not environment-specific
I reproduced the identical crash with the binary built on two different toolchains, to rule out a bleeding-edge-distro issue:
A trivial hello-world Rust binary built on the same images runs fine, so the toolchains themselves are healthy.
Symptom / gdb
Only
ld-linux,libstdc++,libgcc_s,libm,libcare mapped at crash time (ONNX Runtime.sois not loaded for--version).Ruled out
ortis statically linked (default) or dynamic (fastembed→ort-load-dynamic); the.soisn't even loaded at--version.MemSizis ~2KB; bumpingGLIBC_TUNABLES=glibc.rtld.optional_static_tlsdoesn't help.ulimit -s unlimiteddoesn't help.env -itoo.Build notes (in case relevant)
RocksDB (
librocksdb-sys 0.16 / RocksDB 8.10) needsCXXFLAGS="-include cstdint"to compile under gcc ≥13; unrelated to the crash but required to build at all on modern toolchains.Ask
Is
codegraph-serverexpected to work on Linux/aarch64 at this version? Happy to provide a full core dump,LD_DEBUGoutput, or test a patch. The pre-mainstore-through-a-bad-global-pointer suggests a static-initializer / relocation issue in a bundled C/C++ dependency.