Debug runtime crashes

Debug runtime crashes in C++ — with the four heights of help laid out: do it now, make it easier for the next person to accept, work out the right move when you are stuck, and learn the pattern so it stops coming back.

4prompt heights
Open it in the interactive atlas →

The four heights

The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.

Execute — do the immediate task

+
I need you to find why the game client crashes on start so the playtest can run at 10am. Attach the…
I need you to find why the game client crashes on start so the playtest can run at 10am. Attach the core dump from yesterday's run, reproduce the crash locally with debug symbols, and produce a stack trace pointing to the first user-land frame. If it is memory corruption, stop and report that immediately.

Improve — make it easier to accept

+
Before I hand the crash report to the lead, make it easier to approve: put the topmost user frame…
Before I hand the crash report to the lead, make it easier to approve: put the topmost user frame first, annotate which source file and line are in our code versus third-party, and list the variable values of function arguments at the crash point. If the wreck came from an allocation made earlier, highlight the nearest allocation site that is in our code.

Decide — diagnose the stuck moment

+
The client segfaults during initialization on my dev machine. It prints no clear error and the core…

Client crashes at startup with segmentation fault

The client segfaults during initialization on my dev machine. It prints no clear error and the core shows a crash in a third-party graphics lib. I can run under the debugger and I don't know whether the fault originates in our initialization or the library. The studio expects a fix before tomorrow's build. What's the most likely root cause and the quickest debugging steps to pinpoint if our init sequence is violating the library's contract?

Become — change the pattern

+
We repeatedly ship builds that crash for a subset of players and it costs support time and…

Recurring runtime crashes in release builds

We repeatedly ship builds that crash for a subset of players and it costs support time and reputation. Crashes often trace back to late changes in initialization or subtle UB that only shows in optimized builds. What ongoing habit should I change in our development lifecycle to catch these regressions earlier and reduce production crashes?

Next to this one

Other programming language work people do in C++.

Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.

The rest of the map

Same library, five ways in.