Developers sometimes dismiss the initial stack trace from a crash thread when debugging because it doesn’t provide any helpful information. You’d think modern crash reporters would be able to point to the source of a crash, especially when some are focused only on crashes. But, that’s not the case. The alleged offending crash thread can be a red herring, telling only half of the story of why your mobile application crashed.

First, a little bit on how a crash thread is chosen: Each OS has a specific set of rules governing how apps are permitted to run on a device. A watchdog enforces these rules on a device, closing apps as it sees fit. For example, on iOS, any app that runs for more than 30 seconds in the background will be closed. On Android, if the main thread is locked for more than 8 seconds, the OS will alert the user of an ANR.

Crash reporters have trouble showing the correct thread in these cases because by nature, they only show the last exception caught. However, with communication errors among multiple threads, the main thread isn’t the only one a developer should be looking at.

Here, it’s helpful to get more information – to have additional analytics and monitoring tools to build a user and session’s story to assist with debugging.

But before that, let’s spell out the two specific scenarios where you would want to look beyond the initial crash thread:

  1. The background crash

This type of crash is the exact kind of issue that occurs when the watchdog enforces the above-mentioned rule. Here, an app isn’t closed cleanly, and developers have to look at other threads to search for code patterns.

For more info, read here and learn more about how Embrace developers helped a customer generate a testing procedure and reproduce a background crash using our User Timeline.

  1. The deadlock

A deadlock occurs when an app stops responding but doesn’t actually crash. Often, your users will describe this as having a “frozen” app where they can no longer swipe or tap to interact with the application. On Android, this presents as an ANR.

When the app is in the foreground, the main thread cannot remain hung for more than 10 seconds, or else a crash will occur. If you were to look at all threads at the time of the crash, you would find what the term deadlock refers to: one thread is stuck waiting for the required resource another is holding.

The best strategy to solve deadlocks is to avoid them in the first place. Historically, developers have had trouble with locking threads and debugging them. Modern OSs seem to be moving toward lock-free coding strategies and algorithms (e.g. on iOS, Grand Central Dispatch queueing processes) so developers don’t need to face this problem in the first place.

However, when you have no choice, the method to solving a deadlock is to check the debugger multiple times and find which threads are unchanging. Then, you should check the stack traces for those threads and proceed from there.

Each crash is unique, but with a solid set of tools and understanding of different scenarios, teams can develop a strategy to tackle any crash. Crashes are only one part of improving an application’s performance, so you might need other tools like monitoring to solve them.

Sometimes, all you need is a crash report. But there are cases where crash reports are not only not helpful, but can even divert you away from where the real problem is, as is the case with these two situations. If you had a choice, wouldn’t it be better to have more information?

Embrace is your one-stop shop for mobile monitoring and developer analytics. We handle all three of your main needs: application performance monitoring, infrastructure monitoring and error logging.

If you’d like to learn more, check out our website and give us a try or request a demo.