The shared result callback treated every code as an answer, so the 5s
stale ping fired by the slow arm+ASan runner during the 50k-ref-alloc
handler woke waitCallback with retCode=3 and let the test tear the
context down while the handler was still running -- which in turn made
destroyFFIContext err and left the event thread firing on a torn-down
signal (the UBSan fireSync null deref). Honour the same contract the
generated C/C++/Rust trampolines now follow: a progress ping is not a
reply. Tests asserting on the pings use staleCallback instead.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nim-ffi never times a handler out: a hard-cancel mid-call into the
underlying library (Waku/libp2p) can leave it half-applied. Instead, while
a request is still in flight its result callback receives a non-terminal
RET_STALE_WARN every StaleWarnInterval (5s default, Android's ANR interval;
-d:ffiStaleWarnIntervalMs to override), carrying the elapsed milliseconds as
a decimal string. The request always ends with exactly one terminal
RET_OK/RET_ERR — the dev decides what to do with a slow one, nim-ffi does
not decide for them.
This replaces the never-released per-proc {.ffi: "timeout = <ms>".} override
and the defaultRequestTimeout context field (issue #93), whose hard abort
unblocked the caller early. The stale-warn interval is an internal context
seam (staleWarnInterval), not a per-proc pragma.
Codegen: emit RET_STALE_WARN in the C/C++ headers, and guard every generated
trampoline (C, C++, Rust, and the Nim abi=c reply trampolines) to early-return
on the non-terminal code so the repeated callback can't double-free the
one-shot reply box. Typed wrappers ignore the progress signal for now; it is
delivered at the raw result-callback boundary.
Closes#126.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
