Camera ANR analysis case

get log

 

AP Log:
/sdcard/mtklog/mobilelog/APLog_XXXXX

/sdcard/debuglogger/mobilelog/APLog_XXXXX

db:

/data/aee_exp

If the db packaging is not completed, the trace is completed and then export the anr log in the phone /data/anr/.

1. Get the log and search first

ANR in package life (for example, com.mediatek.camera) Find the corresponding PID Check the stack information according to the PID

If there is, Reason: Input dispatching timed out....... content will appear

Then export the anr log in the phone 

adb pull /data/anr/ . 

                                figure 1

ANR analysis process

 APP Idle:

Check the Callstack and see that the callstack of the main thread stops at nativePollOnce (FROM_SWT_JBT_TRACES)

No focus Window ANR Check point:

Check the time point of activity onResume (the activity can be seen at this time), if onResume has not been completed when ANR occurs, it is classified as APP related Issue

Log analysis steps

1. Confirm the ANR occurrence time node

2. View callstack from ANR process main thread

3. Compare the above picture to confirm the problem

4. Specific analysis of specific problems after positioning the problem

Common ANRs are

1. Waiting for lock

The thread status is blocked, and the keyword held by is used to further confirm which thread holds the lock 

Solution Check the code logic to unlock

The thread is waiting, which means that the current thread needs another thread to notify(). It needs to analyze according to the callstack and code to find the thread holding the lock. If many threads hold a lock, there may be resource competition, resulting in the target thread not being able to hold the lock. to the lock

There will be some ANR logs in the exported file, and then search for the package name required in each file. Take com.mediatek.camera as an example.

2.binder sever card owner

The thread state is native and contains callstack:IPCThreadState::waitForResponse-->IPCThreadState::takeWaitDriver

Indicates that the card is stuck at the opposite end of the binder, look for the stack (callstack) of the thread at the opposite end to see where the card is

The way to find the peer is

        1) According to the sysTid of the binder thread, look up the keyword of the binder's communication peer interface in SYS_BINDER_INFO/SWT_JBT_TRACES/kernel_log as outgoing transaction

        2) Find the process name through the peer sysTid in SYS_PROCESSES_AND_THREADS

        3) If it is a Monkey, do not pay too much attention to this serious situation except

3. Native method is too time-consuming

The thread status is Native. It takes time to find which method according to the callstack. Find the corresponding person in charge. 

4. zygote fork process card master

The thread status is Native, confirm Process.zygoteSendArgsAndGetResult in the stack information

In general, it is caused by memory to check whether it is insufficient memory or memory leak

5. Dump takes too long

1. ANR occurs ANR in ... and the thread is dumping 

通过 callstack :appNotResponding / dumpStackTraces

2. Confirm which thread dump time is too long from SYS_ANDROID_LOG

3. Search for the keyword dumpStackTraces process to confirm all dumps when ANR occurs

4. Confirm whether the time difference between the upper and lower processes is greater than 60s or the sum of the dump times of all processes is much greater than 60s

5. After confirming the process, analyze the code processing in detail

Guess you like

Origin blog.csdn.net/I_am_a_loser/article/details/127090111