Testin Crash Analysis Breadcrumb Function Sweepers Crash Problems

The concept of breadcrumbs comes from the fairy tale "Hansel and Gretel". When Hansel and Gretel were walking through the forest, they accidentally got lost, but they found breadcrumbs scattered along the way, which helped them find their way home. Therefore, the role of breadcrumbs is to help developers understand the user's behavior path and locate when and why the user crashed.

What exactly are breadcrumbs in the Testin crash analysis service?

Added breadcrumb feature. Breadcrumbs are similar to log information and are defined by the developer. Breadcrumbs are inserted to record information during application runtime, such as variable values, application status, code progress, user operations, program performance, and callbacks (such as low memory warnings). The SDK version number of the breadcrumb feature of Testin Crash Analysis is 1.7.3 (Android & iOS).

For example, the Android phone's nine-grid unlocking function is familiar to everyone. Common unlocking gestures include Z-shaped, M-shaped, and W-shaped. However, some users set a lot of strange unlocking patterns to prevent the password from being too simple, and often forget the correct operation steps. The same is also reflected in our daily App development process. Through the crash analysis SDK, we can specifically locate which line of code has a problem, but the causes of some crashes and exceptions are often complicated method call relationships, which makes developers unable to fix the bug. Through breadcrumbs, developers can narrow the scope of locating the problem, so as to locate and solve the problem faster.

When the bread crumbs are scattered in the forest

What happens when breadcrumbs are scattered in the forest? A large mobile game company summarized the following key entry points when using breadcrumbs to solve the segment violation crash problem:

Function call stack: The call stack can be used to analyze the causes and consequences of most simple segmentation violation crashes. If you are lucky, you can find and fix the problem by looking at the top two or three layers of the stack. Absolute result errors related to null pointers can hardly hide in front of a complete call stack.

Violation address: Using the violation address and combining it with the calling context, it is easy to infer whether it is a null pointer error or a wild pointer error.

Application end-of-life operations: Generally speaking, for wild pointer errors, function call stack and violation address information are basically of no reference value. They only tell us where the program accessed an address that should not be accessed, but they cannot help us understand why the program accessed it and how it accessed it. For wild pointer segment violation errors, we need to know how the end user approached the crash point step by step. Generally speaking, trace logs can be used for local debugging.

Others: model, application version, memory, user feedback, etc. for reference.

For online crashes, we use testin crash analysis. The new version (1.7.4) provides a very powerful new feature: breadcrumbs, which can be used to collect 100 custom dying messages, which can be well targeted at the third entry point.

What exactly can breadcrumbs in Testin crash analysis do?

To add breadcrumbs, developers only need to insert an API call (after TestinAgent is instantiated). The captured breadcrumbs can help developers:

1. Identify and analyze session events, states, or parameters for debugging.

2. Use this information, along with stack information, diagnostics, and user searches, to determine the source of the problem.

3. Supplement IDE debugging, enabling them to capture useful information about application behavior in order to gain more users.

4. For each breadcrumb session, the start trace automatically stored in the SDK marks the beginning of the user session. Each breadcrumb session has a maximum of 100 breadcrumbs.

The "bread crumbs" of Testin crash analysis can help developers analyze the cause of the crash: what operations did the user perform, what are the variables in the function? Don't let any crash run rampant.