Hardcore Debugging

Solving bugs when nothing else works

Sometimes, your app crashes.

Sh*t happens.

Usually this is annoying, but straightforward to fix. Maybe you messed up the lifetime of a reference, or perhaps there was some subtle race condition you didn’t consider.

But there’s a class of crash far more insidious.

Crashes which originate deep in the kernel memory management system, where the debugger refuses to narc on the culprit.

This crash trace yields sparse detail:

• It’s the main thread, and something concurrency related.

• EXC_BAD_ACCESS suggests we’ve tried to access deallocated memory.

Lady Luck is smiling on us: mercifully, the crash is 100% reproducible. Unfortunately, it lies on a core user flow and slipped through to production.

We need to pull out our advanced tools. In a pinch, there are a couple of techniques to help pinpoint the source of the crash:

• Git Bisect to narrow down through time.

• Manually Symbolicating Crash Logs to narrow down across space.

Today’s blog applies these advanced approaches to solve a real-life mystery crash.

If you’d like to learn more about how crashes are thrown from the kernel memory management system, and can’t wait 3 weeks for Tech Tavern content, please check out my piece “What Is A Crash?”

Enjoying Jacob’s Tech Tavern? Share it! Refer a friend as a free subscriber to unlock a complimentary month of full subscription.