Repository navigation
SIGSEGV: garbage key reaches set_field_by_name_object_tail when a strict arm holds a frozen class instance with a field named caller #9542
Description
Activity
- added a commit that references this issue
on Sep 2, 2026 Root-caused: this is #9499, and it is already fixed on
mainbyc405ce4981(#9522, the root-reload launder), which landed at 15:29 today — after the bisect in this issue. PR #9558 restores the held-out fixture case as the second regression witness; no code change is needed.All three leads in the issue turned out to be wrong, and each is worth recording:
calleris not load-bearing. Renaming the field tozzz, writing it with=instead of+=, or never writing it at all reproduces byte-identically. Any perturbation of the module's object-literal shape set does it. The poison-pill special cases infield_set_by_name.rs/write_helpers.rsare not on the path.- Not a rooting gap in
expr/index_set.rs. Thewith_operands_rooted_across(ctx, &[object, index], &[value], …)group is present and correct, and the emitted IR for the crashing statement is structurally identical with and without the added class — only SSA numbering and twoAnonShapehashes differ. - Not a stale interned key or a string-pool collision. The key was neither stale nor mis-interned: it was the receiver. Instrumenting
js_get_string_pointer_unifiedcaught it taking thePOINTER_TAGbranch on0x7ffd_046b_fceb_06f0;set_field_by_name_object_tailthen read the receiver'sparent_class_idword as abyte_lenof0x800011bcand walked off the heap — which is what the garbage-key hash loop in the backtrace is.
The mechanism is #9499's exactly: a
load %root_slotfolded back into an earlier safepoint's spill slot that was recycled in the hole, so the reload handed the consuming call a different live object. #9499 measured it as "the key stored was the closure allocated three lines earlier"; here it is "the key stored was the receiver". A GDB watchpoint on the machine slot backing the key shows the last write before the faulting read storing the receiver:WRITE val=0x7fff031d8c620058 pc=0x5555556c69fc <- the key string "x" WRITE val=0x7ffd031d8c6b06f0 pc=0x5555556c6b55 <- the RECEIVER, same slot Program received signal SIGSEGV #0 set_field_by_name_object_tail #1 js_typed_feedback_object_set_field_by_name #2 perry_fn_..._strictArmA/B with one variable, on the exact fixture PR #9558 adds:
build result c405ce4981^(mainjust before #9522)SIGSEGV 3/3, output truncated at strict frozen for-of head computedc405ce4981(#9522 launder)exit 0, 82 lines, byte-identical to node v26.5.1, 3/3 Independently confirmed on the #9459 branch (
9f40f65f5): it SIGSEGVs on this shape, and the same tree with onlyc405ce4981cherry-picked runs clean. Reproduced on macOS arm64 and Linux x86-64; the fix verification is Linux x86-64.
A
.ctswhose strict arm contains a frozen class instance with a field namedcaller, written with+=, segfaults — and the fault lands on an earlierstatement in the same function, so it is a module-shape effect rather than a bad
statement.
set_field_by_name_object_tailis hashing a garbage key pointer: thereceiver/key reached the by-name setter with the key naming unmapped memory.
Repro
Attached repro (also reproducible from
test-files/test_gap_9459_property_set_strictness.ctswith a frozenclass CallerCell { caller: number }instance added to its strict arm). Outputstops after
so the crashing statement is the NEXT one —
computedPlus[computedKey] += 1, astrict compound assignment through the
Expr::IndexSetruntime-string-key arm —even though the trigger is the
caller-named class field later in thefunction. Removing only the class-field case makes the whole file pass; removing
any other case does not.
What is known
main+ the fixture content, and on the Sloppyo.x += 1on a frozen object over-throws: Expr::PropertySet carries no strictness field at all #9459 branch with and without thatPR's only behavioural change to this file. Nothing in Sloppy
o.x += 1on a frozen object over-throws: Expr::PropertySet carries no strictness field at all #9459/SIGSEGV after several frozen for-of-head rejections, then a for-of head on an UNfrozen object #9460 is on thepath — the crashing store is the STRICT lane, which both changes leave
byte-identical.
containing the same three statements and the same class; it needs the full
module. That points at a string-pool / dispatch-id or outlining threshold
rather than at the statement.
calleris load-bearing for the trigger, which issuggestive given the poison-pill special-casing that keys on that name in
field_set_by_name.rsandfield_set_by_name/write_helpers.rs.Where to start
The key operand for the strict
o[k] += vlane is rooted bywith_operands_rooted_across(ctx, &[object, index], &[value], …)inexpr/index_set.rs, so this is more likely a stale interned-key handle or adispatch-id/string-pool index collision than a missing root — the #7201/#7640
family, but the guard is present, so the pointer is probably wrong rather than
merely moved. Dumping
--trace llvmfor the crashing function and comparing thekey global against the string pool is the first step.
Found while adding
caller/argumentsreceiver-path coverage totest_gap_9459_property_set_strictness.cts(PR #9519). That fixture omits thefrozen-class-field-named-
callercase with a comment pointing here; it belongsback in the file once this is fixed.