Every time an android runtime exception occurs, the system is confused because the following information is obtained:
ADB logcat:
F/libc (21559): fatal signal 11 (SIGSEGV) at 0x00030010 (code = 1), thread 21578 (M. yunos. browser) I/debug (160 ): **************************************** * ******* I/debug (160): Build fingerprint: 'android/full_mako/Mako: 4.2.1/jop40g/eng. yuanzhijun.20130509.085707: userdebug/test-keys 'I/debug (160): Revision: '11' I/debug (160): PID: 21559, TID: 21578, name: M. yunos. browser >>> COM. yunos. browser <I/debug (160): Signal 11 (SIGSEGV), Code 1 (segv_maperr), fault ADDR 00030010i/debug (160 ): r0 00030000 R1 74514f0c R2 0000001c R3 73792cf8 ...... i/debug (160): backtrace: I/debug (160): #00 PC 001879b2/system/lib/libwebcore. tgl. SOI/debug (160): #01 PC 001b8109/system/lib/libwebcore. tgl. so ......
I only know that an error occurs in libwebcore. Tgl. So. How can I print detailed stack information? At least you need to know which method throws the error.
At first, I tried to write it myself.CodeTo capture signal, and then call backtrace and backtrace_symbols. However, there are no two methods in Android Linux. It is estimated that the GCC extension library must be installed. Put this solution on hold first, try again later.
Then I tried ndk-stack under ndk, but the semantics should be compiled by ndk before it can be used. Anyway, I tried ndk-Stack-sym... -Dump... the cause is that the symbols cannot be found. If the android native application is developed based on ndk, it should be okay, but here I want to debug the android Source Code directly and put it on hold.
Finally, try to use addr2line under ndk. The method is as follows:
Ndk path \ toolchains \ arm-linux-androideabi-4.4.3 \ prebuilt \ windows-x86_64 \ bin \ arm-linux-androideabi-addr2line.exe-C-f-e Y: \ webos_nexus4 \ out \ target \ product \ Mako \ symbols \ System \ Lib \ libwebcore. tgl. so 001879b2
Y: \ webos_nexus4 \ out \ target \ product \ Mako \ symbols \ System \ Lib \ libwebcore. tgl. so is the compiled symbols, and 001879b2 corresponds to the address information in the stack at the beginning:
I/debug (160): #00 PC001879b2/System/lib/libwebcore. Tgl. So
The following structure is obtained after running:
WebCore: inspectorinstrumentation: instrumentingagentsforcontext (WebCore: scriptexecutioncontext *)
Although clumsy, I found at least the method in which the error occurred.
The two ideas mentioned above should be feasible. I will try again later.