future deref segfaults on macOS

[ikappaki]

Issue Description

@(future 42) segfaults on macOS with KERN_INVALID_ADDRESS at 0x1000 (exit code 139).

Likely the same root cause as #722 (nREPL crash), which shows an identical stack trace.

bdwgc thread registration

bdwgc has two modes for tracking threads:

• Implicit: When GC_THREADS is defined, bdwgc's gc_pthread_redirects.h:108-117 redefines pthread_create to GC_pthread_create via a preprocessor macro.

• Explicit: The program calls GC_register_my_thread / GC_unregister_my_thread.

These conflict when both are active. From gc.h, GC_register_my_thread "returns GC_SUCCESS on success, GC_DUPLICATE if already registered", and GC_unregister_my_thread: "Only an explicitly registered thread (i.e. for which GC_register_my_thread() returns GC_SUCCESS) is allowed (and required) to call this function."

What happens on macOS

jank defines -DGC_THREADS globally and links with -Wl,-force_load. On macOS with libc++, std::thread's pthread_create call is an inline function (__thread/support/pthread.h:190). Because it's inline, it compiles within jank's source files where the #define pthread_create GC_pthread_create macro is active. -force_load pulls this instantiation into the final binary, and since inline functions produce a single definition, the linker deduplicates — every std::thread calls GC_pthread_create.

Meanwhile, future() in core.cpp:755-758 explicitly calls GC_register_my_thread and GC_unregister_my_thread:

1. std::thread → GC_pthread_create → implicit registration
2. Thread body: GC_register_my_thread → returns GC_DUPLICATE
3. Thread body exit: GC_unregister_my_thread → called on a non-explicitly-registered thread
4. Thread returns: implicit cleanup runs on already-unregistered state → crash at 0x1000

Why Linux and Windows are unaffected

On Linux, jank uses libstdc++ (not libc++) where std::thread's constructor (std_thread.h:175) delegates to _M_start_thread — unlike libc++, this is a non-inline function compiled inside libstdc++.so. The macro only affects code compiled within files that include bdwgc's headers, so it cannot reach libstdc++'s internal pthread_create call.

On Windows, -DGC_THREADS resolves to GC_WIN32_THREADS (gc_config_macros.h:165-170), so GC_PTHREADS is not defined (gc_config_macros.h:177-183) and the #define pthread_create macro is never active.

Proposed fixes

Fix 1: Add -DGC_NO_THREAD_REDIRECTS

bdwgc provides GC_NO_THREAD_REDIRECTS to suppress the pthread macros while keeping all thread API declarations available. With this define, std::thread calls real pthread_create on all platforms. This is a root-cause fix that removes implicit registration entirely, making all platforms behave identically. One-line CMake change.

Fix 2: Runtime detection with GC_thread_is_registered()

Check at thread start whether implicit registration already occurred; only explicitly register/unregister if it didn't. This works without build system changes but leaves platform-divergent code paths and does not remove the root cause.

Reproduction Steps

1. Create future_deref.jank:

(ns future-deref)
(let [f (future 42)]
  (println "result:" @f))

2. Run from compiler+runtime/:

./build/jank run future_deref.jank

3. On macOS: segfault (exit code 139, KERN_INVALID_ADDRESS at 0x1000).

jank health check

system ──────────────────────────────────────────────────────────────────────────────────────────
─ ✅ operating system: macos
─ ✅ default triple: arm64-apple-darwin25.4.0

─ jank install ────────────────────────────────────────────────────────────────────────────────────
─ ✅ jank version: jank-0.1-alpha
─ ⚠️ jank assertions are enabled; performance will be impacted 
─ ✅ jank resource dir: ../lib/jank/0.1 
─ ✅ jank resolved resource dir: /Users/chaos/src/jank-win/compiler+runtime/build/../lib/jank/0.1 (ignored for dev build)
─ ✅ jank user cache dir: /Users/chaos/.cache/jank/arm64-apple-darwin25.4.0-d09cf498eeed9c98543a7bc1a214c8bd6f581257a63536d4e705da6d90f80762 (not found)

Stack trace

(lldb) bt
* thread #9, stop reason = EXC_BAD_ACCESS (code=1, address=0x1000)
  * frame #0: 0x00000001011e0610 jank`return_single_freelist(fl=0x0000000000001000, gfl=0x0000000101420080) at thread_local_alloc.c:88:11
    frame #1: 0x00000001011dfecc jank`return_freelists(fl=0x000000010420bc28, gfl=0x0000000101420078) at thread_local_alloc.c:107:7
    frame #2: 0x00000001011dfe30 jank`GC_destroy_thread_local(p=0x000000010420bc28) at thread_local_alloc.c:179:5
    frame #3: 0x00000001011dddc0 jank`GC_unregister_my_thread_inner(me=0x000000010420bc00) at pthread_support.c:2396:3
    frame #4: 0x00000001011de07c jank`GC_thread_exit_proc(arg=0x000000010420bc00) at pthread_support.c:2639:3
    frame #5: 0x00000001011dc708 jank`GC_pthread_start_inner(sb=0x000000017025af88, arg=0x000000016fdfa608) at pthread_start.c:77:3
    frame #6: 0x00000001011d4ef4 jank`GC_call_with_stack_base(fn=(jank`GC_pthread_start_inner at pthread_start.c:52), arg=0x000000016fdfa608) at misc.c:2564:12
    frame #7: 0x00000001011dea20 jank`GC_pthread_start(arg=0x000000016fdfa608) at pthread_support.c:2814:10
    frame #8: 0x000000018e30bc58 libsystem_pthread.dylib`_pthread_start + 136

OS Version Information

MacOS 26.4

I acknowledge that:

• I have searched the jank repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[jeaye]

Thanks for the details on this issue! I will dig into it and get a fix. This is a high priority bug.

[jeaye]

This is now fixed!

[ikappaki]

Fixed as part of #846