Intermittent SIGABRT (exit 134) in the optimized binary on nightly-2026-Aug-03

[eschizoid]

The --opt=speed (LLVM) binary built with nightly-2026-August-03-94cbed3 aborts intermittently (exit 134 / SIGABRT, no stderr) at a very low rate — a handful in ~50 runs early, then 0 in 300+ since; not tied to any specific command (fires at random spots across the ~140-command e2e, causing flaky failures at different checks each run). Logic is correct every time it doesn't abort. Signature = a low-frequency refcount/heap bug in the new compiler's codegen.

TODO: get a reliable repro (loop any command), test whether --opt=dev is stable over thousands of runs, then file upstream at roc-lang/roc with the repro. Blocks a clean e2e green + release.

[eschizoid]

Localized: it's the LLVM-optimization backend. Reliable repro found via analyze on a real-sized db (719 activities + streams):

• --opt=speed (LLVM): crashes ~reliably — heap corruption, "modified after being freed", corrupt value varies run-to-run (0x6fff..., 0x3fff..., 0x6fffffffffffffff).
• --opt=dev (native dev backend, no LLVM): 4/4 clean on the same db (slower, ~30s).

Delete the streams → no crash on either. So the bug is in the optimized codegen of the stream-decode path (Streams.roc decode_streams / builtin Json.parse over hundreds of real Strava stream blobs). Cumulative over volume (~360 streams reliably triggers; both halves of the data do). NOT reproducible with synthetic streams matched on count/size/shape/nulls — something in real stream values/encoding.

Workaround: build with --opt=dev until the optimizer bug is fixed.
Next: minimal shareable repro (anonymized real stream blobs, no tokens) → file at roc-lang/roc.

[eschizoid]

⚠️ CORRECTION: the Bug A characterization below (compile-time-constant "") is wrong — a runtime "" crashes identically and Sqlite.query_many! is not required. See the correction comment for the validated trigger + control matrix.

---

Two more memory-corruption symptoms (same family as this issue?)

While re-enabling the e2e suite in CI (#38) and probing the linux build, two additional deterministic memory-corruption behaviors surfaced. Both look like heap/string corruption in the new (Zig) backend's codegen, same family as the SIGABRT tracked here — possibly the same root cause, possibly distinct triggers. Documenting so the repro material is in one place before filing upstream.

A — constant empty-string interpolation -> heap corruption (SIGABRT)

Symptom: deterministic SIGABRT (exit 134). Backtrace: abort -> malloc_*report -> nanov2_guard_corruption_detected -> ... -> roc_builtins_str_concat. Hits --opt=dev too, not just --opt=speed.

Trigger: a compile-time-CONSTANT "" used in a string op — specifically interpolated into a SQL string that then runs through Sqlite.query_many!. A runtime-built "" is fine; only the constant form corrupts.

Where it hit:

• plan all — week_filter = match scope { AllTime => "" ... }, then ${week_filter} in the query.
• bare activities — parsed to a fully-constant tag Activities(30, ""), whose constant "" propagates into the query filter.

Isolation: a minimal clause = if 1==1 "" else "x"; Stdout.line!("...${clause}...") does not reproduce — it needs the fully-constant "" and the SQLite / str_concat output path together.

Workaround (shipped in #38): never interpolate an optional SQL filter — bind it (:x = '' OR ...) or a scope flag.

B — Json.to_str corrupts a string field's tail (LINUX ONLY, silent, no crash)

Symptom: no crash (exit 0). A string field in JSON output has its tail overwritten with garbage bytes. stride plan add 2099-01-01 ... on linux emits (NUL/control bytes shown escaped):

output: {"id":1,"session_type":"vo2max","target_date":"2099-01^@^O^@"}

target_date should be "2099-01-01".

Decisive evidence — it's the SERIALIZATION, not the stored data:

STORED target_date in db: 1|'2099-01-01'|10       # correct, length 10
output JSON target_date:  "2099-01" + ^@^O^@   # last 3 chars clobbered

The value is written to SQLite correctly; only the Json.to_str output corrupts it. Same command on macOS -> correct output. session_type (also an argv-derived string, in the same record) serializes fine — so it's position/layout-specific, not "every string."

Impact: silent data corruption in JSON output on the linux build (--opt=dev) — arguably worse than a crash (a downstream JSON consumer chokes on the embedded NULs). This is why stride's e2e job currently runs on macOS and why linux release binaries are gated.

Repro sketch (to minimize): build { id: I64, s1: Str, s2: Str } where s2 is an argv-derived (Str.from_utf8) 10-char string, Json.to_str it on linux, inspect s2's bytes.

---

Both are 100% reproducible. B is the higher-priority one (silent > crash). A CI job that reproduces on demand + full backtraces are available.

[eschizoid]

Correction to the Bug A characterization above

I built standalone minimal repros for both bugs and, in doing so, disproved the "compile-time-constant """ framing I gave for Bug A above. Correcting the record before this misleads anyone (the earlier comment is edited with a pointer here).

What Bug A actually is

Not constant-specific, and not tied to Sqlite.query_many! execution. The trigger is an empty Str interpolated into a long-enough string, which corrupts the heap while the string is being built (roc_builtins_str_concat), aborting with SIGABRT (exit 134). It is size/realloc-sensitive — short strings don't trip it — consistent with a length/capacity miscalculation for the zero-length operand.

Control matrix (standalone repros, each deterministic 5/5 on macOS, --opt=dev)

#	the empty / interpolated value	path	result
1	constant "" (tag payload Activities(30,""))	into a long query-shaped string	crash 134
2	runtime "" (read from db, SELECT '')	into the same string	crash 134
3	non-empty "Ride"	into the same string	exit 0
4	runtime ""	short print "before[${e}]after"	exit 0
5	runtime ""	builds the query string, no query_many!	crash 134

• 1 vs 2 → origin (constant vs runtime) is irrelevant; my "constant-only" claim was wrong.
• 3 → it's the empty value, not the query shape.
• 4 vs 5 → it's the string build, not query execution; and a short string doesn't trip it.
• Extra probes: "${e}${e}" / "${e}${e}${e}" (short adjacent empties) do not crash — length matters.

Actual backtrace (macOS .ips crash report for the reduced repro)

abort
malloc_vreport → malloc_report        (heap corruption detected)
_realloc → roc_realloc
roc_builtins_str_concat               ← string being built here
roc__proc_257 … roc_main

Net for filing upstream

Report it as "interpolating an empty string into a sufficiently long string corrupts the heap in str_concat (realloc guard); origin-independent; string-build not query-exec." The stride workaround is unchanged — binding a possibly-empty SQL fragment as a parameter (:x = '' OR col = :x) sidesteps it regardless of the exact mechanism.

Bug B status

The Bug B repro is validated on macOS (byte-dump proves the Str is intact pre-Json.to_str; output is correct there — the whole point). The Linux tail-corruption was observed in the full stride binary; the reduced standalone repro has not yet been run on Linux, so that reduction still needs a Linux confirmation before it's filed. Not asserting the Linux failure from a macOS run.

(Both reduced repros + the five Bug-A control programs live in upstream-repros/ in the stride tree.)

[eschizoid]

Bug A is fixed upstream

roc#10570 (RcEffect ownership) fixes the empty-string strConcat heap corruption: its empty-right fast path returned a shared/static allocation while its contract promised uniqueness, so the following concat's in-place realloc corrupted the heap — exactly the ≥24-byte-prefix + suffix + empty-operand shape reduced in roc#10595.

Confirmed FIXED on nightly-2026-August-04-1cb06bc: the minimal repro is 10/10 clean (was 10/10 crash on Aug-03). roc#10605 pins that repro as a regression test and closes roc#10595. stride's nightly pin is bumped to Aug-04. The bind-don't-interpolate workarounds stay — they're correct SQL regardless.

Bugs B and C in this issue are NOT fixed by #10570. On the Aug-04 nightly, bug C still crashes stride sync ~25%, and bug B (Json.to_str linux tail corruption) is very likely still live. So they're distinct alloc bugs in the Json.parse / Json.to_str paths, both still LAYOUT-BOUND (bug C re-confirmed: ~270 bare standalone runs on Aug-04, 0 crashes, while the full binary corrupts). No minimal repro for either; not separately fileable.