codedb v0.2.1 (prebuilt binary and self-built) crashes immediately with SIGSEGV on Arch Linux rolling, kernel 6.18.13-arch1-1, x86_64.
Stack trace (identical across all invocations):
#0 0x000000000109be78 main.main (codedb + 0x9be78)
#1 0x000000000106ae5f start.callMain (codedb + 0x6ae5f)
#2 0x000000000106aa8e start._start (codedb + 0x6aa8e)
Binary info:
ELF 64-bit, statically linked, x86-64, stripped
Every mode crashes identically:
codedb --help — segfault
codedb mcp <path> — segfault
codedb serve <path> — segfault
- Piped input (
echo | codedb) — exit 139
setsid, TERM=dumb — exit -11
What was tried:
- Prebuilt binary from install script — segfault
- Prebuilt binary from GitHub releases v0.2.1 — segfault
- Prebuilt binary from releases v0.2.0 — segfault
- Prebuilt binary from releases v0.1.0 — segfault
- Built from source with Zig 0.15.2 (patched out macOS codesign step) — segfault (same trace, different offsets)
- Built from source with
-Dtarget=native-linux-gnu — segfault
- Wrapped with
script -qc PTY — segfault
- Python
pty.openpty() — segfault
Environment:
Linux archlinux 6.18.13-arch1-1 #1 ZEN SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
Assessment:
The crash occurs in main.main during Zig runtime initialization, before any application code runs. This strongly suggests a Zig standard library incompatibility with kernel 6.18.13 rather than a TTY or subprocess issue.
codedb v0.2.1 (prebuilt binary and self-built) crashes immediately with SIGSEGV on Arch Linux rolling, kernel 6.18.13-arch1-1, x86_64.
Stack trace (identical across all invocations):
Binary info:
ELF 64-bit, statically linked, x86-64, stripped
Every mode crashes identically:
codedb --help— segfaultcodedb mcp <path>— segfaultcodedb serve <path>— segfaultecho | codedb) — exit 139setsid,TERM=dumb— exit -11What was tried:
-Dtarget=native-linux-gnu— segfaultscript -qcPTY — segfaultpty.openpty()— segfaultEnvironment:
Assessment:
The crash occurs in
main.mainduring Zig runtime initialization, before any application code runs. This strongly suggests a Zig standard library incompatibility with kernel 6.18.13 rather than a TTY or subprocess issue.