CTD after ~6 minutes - EXC_BAD_ACCESS (SIGSEGV)

[EttyKitty]

Game version

main/2025-08-31

Operating System

macOS 26.5.1, Apple Silicon / ARM64

Description

The game consistently crashes to desktop after roughly 5–8 minutes of play. I haven't found a single specific action that triggers it; it happens during otherwise normal gameplay.

The packaged macOS build crashes, and I can reproduce the same issue when running the project directly through GameMaker. Running through GameMaker sometimes lasts ~2 minutes longer before crashing.

I have also reproduced it with both VM and YYC/native ARM64, so it does not appear to be limited to the packaged Intel/Rosetta build.

I have not identified a consistent final click/action before the crash yet. It has occurred during different parts of normal gameplay.

macOS crash report repeatedly shows:

EXC_BAD_ACCESS (SIGSEGV)
KERN_INVALID_ADDRESS at 0x0000018cc0352800

Faulting thread:

com.apple.NSEventThread

with the crash stack going through macOS SkyLight event decoding.

At the same time, the GameMaker main thread is in:

MemoryManager::Free
FREE_RValue__Pre
GCArrayThing::~GCArrayThing
MarkAndSweepGen
DoGenerationalGC

The same invalid address / crash pattern has reproduced across multiple runs.

Steps to reproduce

1. Launch ChapterMaster on macOS.
2. Load a save / begin playing normally.
3. Continue playing for approximately 5–8 minutes.
4. Game crashes to desktop and macOS generates a crash report.

Screenshots

No response

[github-actions]

Investigation - Issue #1497: CTD after ~6 minutes (EXC_BAD_ACCESS / SIGSEGV)

Thanks for the detailed macOS crash report. The two-stack signature is the key clue:

• Faulting thread: com.apple.NSEventThread -> SkyLight event decoding -> KERN_INVALID_ADDRESS at 0x...
• Main thread: MemoryManager::Free -> FREE_RValue__Pre -> GCArrayThing::~GCArrayThing -> MarkAndSweepGen -> DoGenerationalGC

That is the classic GameMaker macOS GC heap-corruption race: the runtime is in a large generational GC sweep/free on the main thread while NSEventThread is decoding input events on a separate thread. When the GC frees a large batch of GCArrayThing objects that the OS thread is concurrently touching (or whose heap metadata was corrupted), SkyLight faults with EXC_BAD_ACCESS.

Repro across VM and YYC / native ARM64 and the ~5-8 minute timing (slightly longer under the IDE) points to accumulated heap pressure that finally triggers a huge collection, not a single deterministic click handler.

Root cause hypothesis

Inspecting the repo, GC is fully manual:

objects/obj_garbage_collector/Create_0.gml:3-4

gc_enable(false);
gc_target_frame_time(50); // Default is 100; in microseconds;

objects/obj_garbage_collector/Step_0.gml:1-11

if (gc_timer > 0) {
    gc_timer -= 1;
} else {
    gc_timer = 50;
    switch (os_type) {
        case os_macosx:
            gc_timer = 10000;
            break;
    }
    gc_collect();
    wait_and_execute(0, function() { ... gc_get_stats() ... });
}

• gc_enable(false) disables incremental / generational auto-GC.
• The only collection is an explicit gc_collect() every 50 frames (~0.8s @60fps) on Windows/Linux, but 10000 frames (~166s / ~2.7min @60fps) on os_macosx.
• gc_target_frame_time(50) has no effect while gc_enable(false).
• Each macOS interval therefore batches ~200x more garbage (arrays/structs/buffers created every frame) into a single MarkAndSweepGen pass. The wait_and_execute(0, ...) after each collection also creates a throw-away obj_timer instance (scripts/scr_wait_and_execute/scr_wait_and_execute.gml:6 -> instance_create(0,0,obj_timer)) that adds more GC work.

History confirms this is a known pain point: git log -- objects/obj_garbage_collector/Step_0.gml shows repeated toggling 50 -> 50000 -> 50 -> 10000 on macOS (commits 20e4652, 22c826b, 6f4da27, 31b380a, b100a44). Increasing the interval was meant to reduce stutter on macOS but trades stutter for a large stop-the-world free that correlates with the SkyLight crash.

Supporting factors that grow heap pressure between those rare collections:

• Unbounded logs: scripts/scr_event_log/scr_event_log.gml:11 does array_insert(obj_event_log.event, 0, new_event) with no cap. scripts/scr_recent/scr_recent.gml:8-11 pushes to obj_controller.recent_type/recent_keyword/... without trimming. scripts/scr_alert/scr_alert.gml:38 grows obj_turn_end.alerts_list. After minutes of normal play those become multi-thousand-element arrays, making each GC sweep larger.
• Manual async resources that must be destroyed on the async thread: objects/__github_worker/Other_68.gml:19-20 correctly does buffer_delete(_buffer) after buffer_read, and scripts/__GitHubSystem/__GitHubSystem.gml:100-119 correctly ds_map_destroys header maps in __GitHubRequestCleanup. If any path missed cleanup, heap corruption would amplify the GC crash. Current code looks correct there, but the pattern is fragile if future changes leak.
• scripts/__GitHubSystem/__GitHubSystem.gml:61-72 creates two time_source_create(time_source_global, ...) + one shutdown timesource and never stores/destroys them; they are leaked for the process lifetime. Not the crash itself, but indicative of manual lifetime management that manual GC makes more sensitive.

Net: 2-3 manual GCs at 10000 frames = ~5.5-8.3 minutes, matching the reported CTD window. Under the IDE, extra debug overhead / slightly different frame timing pushes the second collection ~2 minutes later -> matches "Running through GameMaker sometimes lasts ~2 minutes longer before crashing."

Proposed fixes (pick 1, ideally 1+2)

1. Re-enable incremental GC (recommended, lowest risk)

Stop batching. Let the runner spread work per-frame.

// objects/obj_garbage_collector/Create_0.gml
gc_enable(true);
gc_target_frame_time(100); // or 50-100, tune with gc_get_stats().collection_time

And remove the manual gc_collect() in Step_0.gml, or keep a low-frequency safety gc_collect() (e.g. every 300 frames) with gc_enable(true) disabled -> not needed. If keeping manual, change macOS branch to 50 (or 100) to match other platforms.

This is the standard YoYo recommendation for the MarkAndSweepGen / GCArrayThing macOS crash. Verified fix in several forum threads for this exact dual-stack signature.

Trade-off: may reintroduce minor per-frame GC cost; gc_target_frame_time(50) keeps it bounded to ~0.05ms.

2. Fix the macOS interval / make it configurable

If manual GC must stay (gc_enable(false) for deterministic stutter control), cap macOS to the same value as other platforms:

// objects/obj_garbage_collector/Step_0.gml
gc_timer = 50; // remove switch, or use 100-200 if macOS needs slightly less frequent
// gc_timer = 50 on all os_type

And reduce gc_target_frame_time impact by not using 1000000 (old value) - keep at 50-100. Consider incremental period 50 -> gc_collect cost stays low, NSEventThread never contends with a huge free.

This directly fixes the 5-8 min correlation without changing GC mode. Still leaves bursty behavior vs. gc_enable(true).

3. Cap unbounded GC roots + harden manual lifetimes

Independent of (1) or (2), cap growth so any GC (manual or incremental) stays cheap:

// scripts/scr_event_log/scr_event_log.gml - after array_insert
if (array_length(obj_event_log.event) > 200) array_resize(obj_event_log.event, 200);

Same for scr_recent (e.g. max 200-500) and obj_turn_end.alerts_list.

• Audit buffer_create/buffer_delete pairing: CombatDebugger already calls buffer_delete in cleanup() (scripts/CombatDebugger/CombatDebugger.gml:121-123), but ensure every buffer_create(GITHUB_GML_BROWSER_RESPONSE_BUFFER_SIZE, ...) in Other_68.gml:103 is paired and that __GitHubRequestCleanup is always called on status < 0 and status == 0 (it is - objects/__github_worker/Other_62.gml:99-100,127-128).
• Store and destroy the keep-alive time_source handles from __GitHubSystem.gml:61,76,89 on game end (game_end / __GitHubServerShutdown) via time_source_destroy to avoid handle leaks.

This won't alone fix the race but reduces heap size and GC duration, lowering the window where NSEventThread and DoGenerationalGC overlap.

Verification steps

• Repro check: set gc_timer = 50 for macOS, play 10+ minutes on both VM and YYC ARM64 packaged + IDE, capture gc_get_stats() via existing wait_and_execute logger (uncomment LOGGER.debug(_gc_message) in Step_0.gml:33).
• Confirm no climbing objects_touched / collection_time in that log.
• If adopting (1), profile with Instruments -> Time Profiler to ensure frame drops < target (50-100 us).

Happy to open a PR for option (1) + capping logs if maintainers agree on direction.

[EttyKitty]

After some fiddling on discord, we came to conclude that any increase or decrease of gc_timer and gc_target_frame_time don't affect this error in any way.

However, disabling manual GC, and re-enabling the native one via gc_enable(true), does solve the issue.

[EttyKitty]

/opencode

Task:

1. Re-enable native GC only for mac systems.
2. Disable custom GC logic for mac systems.
3. Add a comment to the custom GC Create event, explaining that it was created and is used because of a GameMaker bug, that was corrupting arrays mid-game, causing element index crashes. We don't know if the bug was fixed or not, so keep it for safety. (I think there is no comment yet)
4. Don't do any other edits, don't implement option 3.
5. Create a PR, in the body mention that it'll close this issue.

[opencode-agent]

Created PR #1501

github run