SIGSEGV from explicit gc() inside try/catch on a real workload (minimal cases all pass) #1830

Activity

1. proggeramlug commented on May 26, 2026

   

   proggeramlug

   on May 26, 2026

   ContributorAuthor

   More actions

   Found the root cause and opened #1836.

   Why every minimal repro passed but a real workload crashed: the trigger is not gc() in a try/catch per se — it's gc() (or any GC) running in a catch after the exception propagated up from a deeper function that had pointer-typed locals. Every minimal repro here throws at the same frame as the catch, so there are no deeper frames involved.

   Mechanism: js_throw unwinds with longjmp, which jumps straight back to the setjmp site and skips the epilogues of the functions being unwound past — including their codegen-emitted js_shadow_frame_pop calls. The precise-root shadow stack's frame_top is then left pointing at the orphaned (now-dead) callee frames. The shadow stack is consumed by the GC (mark phase + the copying/evacuating fast path), and on the copying path the collector reads and writes the rewritten pointer back through slot pointers that, for an orphaned frame, point into stack memory that has already been unwound and is being reused by the catch body. Whether that reused memory passes the GC's valid_ptrs classifier decides crash-vs-silently-fine — hence the load-dependent heisenbug, and why PERRY_GEN_GC=0 doesn't reliably help (the mark path scans the orphaned frames too). This matches the #1824 profile.

   Fix (#1836, runtime-only, no codegen changes): js_try_push captures a shadow-stack savepoint before the protected region can push any callee frames; js_throw restores it right before the longjmp, dropping the orphaned frames before any later GC can scan them.

   @WebReflection — a deep-throw-then-gc() shape should stop crashing once this lands. If you still see a crash on your program after, please reopen with the surrounding shape; thanks for the report.
2. proggeramlug

   added a commit that references this issue on May 26, 2026

   fix(gc): restore shadow stack on exception unwind (#1830) (#1837)

   ...

   f124147
3. proggeramlug

   closed this as completedin #1837on May 26, 2026
4. WebReflection commented on May 27, 2026

   

   WebReflection

   on May 27, 2026

   More actions

   to whom it might concern, this was the failing example:

   import { App, Text, Button, VStack, State } from "perry/ui";
   
   const count = State(0);
   const gone = State(false);
   
   let obj = {};
   let wr = new WeakRef(obj);
   
   App({
     title: "My Counter",
     body: VStack(8, [
       Text(`Count: ${count.value}`),
       Text(`Gone: ${gone.value}`),
       Button("Increment", () => {
         count.set(count.value + 1);
         if (count.value > 3) {
           obj = null as any;
           try {
             gc();
           } catch (e) {
             count.set(e.message);
           }
         }
         else if (count.value > 4) {
           gone.set(wr.deref() ?? true);
         }
       }),
       Button("Decrement", () => count.set(count.value - 1)),
       Button("Reset", () => count.set(0)),
     ]),
   });

   the app compiles and works fine but if you click increment 4+ times it bails out.
5. proggeramlug

   added a commit that references this issue on Jul 18, 2026

   runtime: scoped interpreter for new Function — ajv / fast-json-string…

   ...

   3911d52