You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SIGSEGV in renderSidebar: NaN-boxed pointer dereferenced as raw address #13
Crash (SIGSEGV) when clicking Disconnect button in Mango. The crash occurs in renderSidebar which is called after clearing sidebar state arrays.
Crash Details
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x7ffd00059c405610
The faulting address 0x7ffd... has tag 0x7FFD which is POINTER_TAG — a NaN-boxed pointer value. The codegen is using this NaN-boxed f64 as a raw memory address instead of extracting the lower 48 bits first.
The Disconnect handler clears sidebar arrays (sidebarDbNames = []) then calls renderSidebar(). The function accesses widget handles or string values from module-level variables. The codegen generates code that treats NaN-boxed pointer values (f64 with tag 0x7FFD) as raw memory addresses, causing an access to 0x7ffd00059c405610 which is in unmapped memory.
This is related to #10 — the codegen's is_string / is_pointer optimization strips NaN-boxing tags from local variables, but when those values are later used in contexts that expect raw pointers, the full NaN-boxed bits (including the tag) are used as the address.
This appears to be fixed by the NaN-boxing corrections in v0.4.37 (GH-10/GH-12) and the earlier module-level variable type fixes in v0.4.28.
Verified with test cases that reproduce the exact pattern described:
Module-level arrays cleared via reassignment (arr = [])
Function called after clearing that accesses those arrays
Nested connect/disconnect/renderSidebar cycling
All scenarios work correctly — no SIGSEGV, no pointer corruption. The original bug was likely caused by the same is_string/is_pointer NaN-boxing issue where I64 pointers were being stored/loaded with POINTER_TAG bits still present.
Activity
proggeramlug commentedon Apr 1, 2026
This appears to be fixed by the NaN-boxing corrections in v0.4.37 (GH-10/GH-12) and the earlier module-level variable type fixes in v0.4.28.
Verified with test cases that reproduce the exact pattern described:
arr = [])All scenarios work correctly — no SIGSEGV, no pointer corruption. The original bug was likely caused by the same
is_string/is_pointerNaN-boxing issue where I64 pointers were being stored/loaded with POINTER_TAG bits still present.fix: x86_64 ABI mismatch — all extern "C" fn -> bool changed to i32/f…
fix: x86_64 SIGSEGV in Contract.call() tuple return — array callbacks…