At present, mPaaS Android uses Crash SDK to deal with flash backoff. Crash SDK is a powerful Crash log collection SDK on Android platform, with a very high Crash collection rate and complete and comprehensive Crash log information. The generated log content is very helpful for problem tracking and resolution.
In our daily operation and maintenance, we often encounter some flashbacks, and we cannot see the cause directly from the flashbacks stack, especially for some non-Java Native flashbacks. Here we share how to use Crash SDK to analyze the flashbacks under the mPaaS framework.
Description of the packet analysis tool blinks
For mPaaS users, the original flash back information is usually exported from the FLASH back analysis platform on MAS. Therefore, it is difficult to read the information directly. You can download LogAnalyzer, a Chrome plug-in.
LogAnalyzer will convert the log text content generated by Crash SDK into HTML pages with strong visual effects. The functions are powerful and mainly include:
- Highlight key information in logs and use different colors to distinguish them.
- Preview the overall structure of log content to quickly locate key content;
- Common crash cause alerts;
After installing the Chrome plug-in, you need to perform the following operations
1. Change the file extension to.txt
The default file suffix on the MAS is. Dat. You need to change the file suffix to.
2. Modify the plug-in configuration
By default, any Chrome plug-in cannot access the url of a file. You need to perform the following operations in the Chrome plug-in.
1. Open the Chrome plugin management page, Chrome :// Extensions /
2. Locate the LogAnalyzer plug-in and click “Details” to go to Settings:
3. Select the option to allow access to the file URL. 4. Open or refresh the log page, and LogAnalyzer takes effect.
3. Effective effect
After you drag the log file to Chrome, you can see that the fields of the flash back information are displayed in different colors after the plug-in takes effect.
The instructions for first opening are as follows:
The following is a snapshot of the flash rollback:
Example of flash regression analysis
In daily operation and maintenance, we often encounter some non-Java Native modules flash back, such as UC. In such cases, you can only contact the UC team for support. In many scenarios, the root cause of flash retreat is not UC, but UC.
This section describes how to deal with the UC kernel flash rollback that is commonly encountered in daily OPERATION and maintenance.
1. A null Java pointer causes UC flash rollback
We can see the following flash back on the flash back point (the client APK related information has been hidden). If we only have no clue from this point, we will continue to look at the log:
When we saw the logcat node information, we found clues. First, we saw the keyword: begin to generate native report, which indicated that the current log was reported by the flash back log. We looked further, the logcat node printed the abnormal stack information.
As you can see from the stack information, the underlying null pointer was triggered by the precreate operation, which caused the initialization exception and finally triggered the flash back. The solution is to temporarily turn off pre-creation to avoid flashbacks.
From the above case, we can see:
- The flash back of Native is not necessarily caused by the Native module, but may be caused by the abnormality caused by Java, thus causing the flash back of Native.
- Begin to Generate native report You can view the LogCAT information about the flash back to help locate context logs about the flash back.
2. The upper-layer OOM causes UC flash rollback
First of all, we can see the log of the reported flashback point as shown in the figure below. The flashback point is in RenderThread, and we also have no clue.
We continued to look hard and searched for begin to Generate Native report reporting nodes in the Logcat node. We saw a large number of abnormal logs of the underlying OOM, and it was basically determined to be the cause of OOM.
All that’s left is to find out where the OOM triggers.
Click the memory node in the flashback, the basic reason is clear, the Vmsize of the current mobile phone has basically reached the maximum, we know that for 32-bit processes, the APP can use the maximum Vmsize of 3GB, but when running on a 64-bit CPU, the maximum Vmsize can exceed 3GB. Close to 4 gb.
However, due to the kernel needs to occupy a part and the differences of different ROM versions, we find the following rules: for Android 8.1.0 and later systems, most of the VMsizes of native OOM crash occur in the position of 3.5-3.9G, which is relatively concentrated. So the solution of the following case becomes how to solve OOM.
3. The FD is incorrectly disabled, causing UC to blink
The reported log is shown in the figure below. We can probably only see that SIGILL may have voluntarily crashed, and the collapse of ILL_ILLOPC indicates an illegal operation.
Then we continue to look at the begin to Generate native report of the logcat node. We basically confirm that the reason is that the FD object used by UC is closed by other programs.
Then UC provided a tool kit with FDscan. After rechecking, we found that the input stream object that UC called shouldIntercept callback was closed by other modules. As a result, UC found that the FD object had been closed when using it, so it crashed. The final solution becomes the user to solve the problem of fD-off by mistake in other modules.
conclusion
Based on the above Case analysis, in the Case of flash retreat of Native module, if the cause cannot be seen from the direct flash retreat stack, don’t be hasty, you can search begin to generate Native report to find the crash context. You can learn more about the logcat flash context logs. For OOM type problems, you can view the current memory statistics.
About mPaaS MAS
MAS mobile analysis service: through the collection and analysis of multi-terminal buried point data, realize the monitoring of product core indicators.
Supports application stability analysis, including blinking back monitoring, exception monitoring, performance monitoring, and user diagnosis, helping developers discover and locate problems in a timely manner.
It helps enterprises to better complete business monitoring, user insight and behavior analysis, guide product iteration, refine product operation, assist marketing decisions and accelerate business commercialization.
Click here to learn more about MAS
read
- “MPaaS Security Hardening” takes you through applications in other people’s homes
- Troubleshooting guide | about mPaaS – iOS applet doesn’t open solution of the problem
- Log in! Let’s Start Coding
– END –