We know that the Android NDK program will generate a tombstone backtrace when it crashes (or take advantage of the ADB Logcat Crawl), and from this backtrace we can see which function caused the crash, but usually because we publish it is Rele ASE version, can not take advantage of the address information in the BackTrace directly to the source code and line number, when the error that caused the crash is not very obvious, for us to solve the problem is not very helpful.
Usually we re-compile a debug version and try to reproduce the crash. There are two problems, one is that if we do not know the recurrence step, or the probability of recurrence is very low, the efficiency is not high, second, we may not always meet the conditions of crash, and once the version is released, the debug version is used to replace the release in the user scene Version is also very cumbersome (and may not even be possible).
In fact, there is one way to solve this problem. We know that the release version of the library file also has the DYNAMIC SYMBOL TABLE, you can use the command objdump-t-R <your so> (and redirect to a text file) to view, and then you can use the same command to see the debug Version of the DYNAMIC SYMBOL TABLE, by comparison, it is not difficult to find that their format is the same, you need to focus only on the first column (symbol address) and the last column (symbol name).
Next, you search the debug version of the DYNAMIC SYMBOL TABLE for the name of the function that caused the crash, and note its SYMBOL address, and then you just need to add an offset to the address, you can use the Addr2line command to locate the source code and line number. What is the offset? Note that the last column of the #00 pc in BackTrace (enclosed in parentheses), where there is a +n after the function name, is the offset of the crash position (note that it is a 10 binary number, and the symbol address is a 16 binary, you need to do the conversion before adding).
It is important to note that because the release version is usually optimized, the offsets in the backtrace are not necessarily very accurate, but not too far from the actual value, you can use the debug version to do a comparison test can be verified. Now you can try this method and hopefully this will help you improve the efficiency of solving crash problems.