> To figure out this crash, you will need to use the addr2line tool
> manually.
> 1) Find the path to the addr2line enter this command in the build env:
> ~/mydroid$ find . -name *addr2line
> 2) Find the location of the symbol directory enter this command in the
> build env:
> ~/mydroid$ find . -name libopencorehw.so
> 3) Combine the two to manually parse this crash:
> <path_to_addr2line_tool>\<addr2line_tool_name> -f -e
> <path_to_symbol_directory>\<shared_lib_you_are_interested_in>
> 0x<AddressFromTheStackTrace>
> From thestacktrace:
> I/DEBUG ( 705): #00 pc 00004390
> /system/lib/libopencorehw.so
> I/DEBUG ( 705): #01 pc 000dc942
> /system/lib/libopencore_player.so
> I/DEBUG ( 705): #02 pc 000dc95a
> /system/lib/libopencore_player.so
> I/DEBUG ( 705): #03 pc 000dc9f8
> /system/lib/libopencore_player.so
> I/DEBUG ( 705): #04 pc 000b9b66
> /system/lib/libopencore_common.so
> You form the addr2line commands manually.
> This line:
> I/DEBUG ( 705): #00 pc 00004390
> /system/lib/libopencorehw.so
> Would be turned into this line:
> <path_to_addr2line_tool>\arm-eabi-addr2line -f -e
> <path_to_symbol_directory>\libopencorehw.so 0x00004390
> And so on ...
> I/DEBUG ( 705): #01 pc 000dc942
> /system/lib/libopencore_player.so
> <path_to_addr2line_tool>\arm-eabi-addr2line -f -e
> <path_to_symbol_directory>\libopencore_player.so 0x000dc942
> I/DEBUG ( 705): #02 pc 000dc95a
> /system/lib/libopencore_player.so
> <path_to_addr2line_tool>\arm-eabi-addr2line -f -e
> <path_to_symbol_directory>\libopencore_player.so 0x000dc95a
> I/DEBUG ( 705): #03 pc 000dc9f8
> /system/lib/libopencore_player.so
> <path_to_addr2line_tool>\arm-eabi-addr2line -f -e
> <path_to_symbol_directory>\libopencore_player.so 0x000dc9f8
> I/DEBUG ( 705): #04 pc 000b9b66
> /system/lib/libopencore_common.so
> <path_to_addr2line_tool>\arm-eabi-addr2line -f -e
> <path_to_symbol_directory>\libopencore_player.so 0x000dc9f8
> ... ETC ETC until you have the entire list.
> Example for a crash I've seen:
> #00 pc 0000e234 /system/lib/libc.so
> Corresponds to this:
> ./prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/arm-eabi-addr2line -
> f -e ./out/target/product/generic/symbols/system/lib/libc.so
> 0x0000e234
> Returns:
> strlen
> bionic/libc/arch-arm/bionic/strlen.c:62
> Then you look in the files/line numbers indicated and debug it
> further.
> I hope this could help...
> Jorge
> On Mar 25, 10:25 am, rajat <rajat.n...@gmail.com> wrote:
> > Hi
> > While trying to debug native C libraries, upon receiving a SIGSEGV,
> > the core dump thrown does not map address values to symbols as seen in
> > DDMS. As mentioned above this is happening due to stripping of
> > binaries.
> > How can we prevent such stripping in Android or obtain detailedstack
> >tracedespite stripping ?
> > Are there any changes we need to make to the Makefiles ?
> > Thanks in advance
> > On Feb 13, 1:47 am, fadden <fad...@android.com> wrote:
> > > On Feb 12, 1:59 am, "click...@gmail.com" <click...@gmail.com> wrote:
> > > > I am looking for little more informations rather than Hex values.
> > > > Like the backtrace feature where thestackhex values is mapped to the
> > > > function names and function names are visible.
> > > The device can't show these, because the symbols are stripped out of
> > > the libraries before they are installed on the device. They do exist
> > > in the build tree; since you're doing your own builds, you can find
> > > them in the appropriate "symbols" directory under "out/".
> > > Given that, you can use "arm-eabi-addr2line" to convert the symbols,
> > > or use gdb/gdbserver to do debugging directly on the device. Make
> > > sure you're using the "out" directory that corresponds to the binaries
> > > installed on the device.
> > > In any event, discussions about debugging native libraries might be
> > > more appropriate for android-porting or android-platform at this time.- Hide quoted text -
> - Show quoted text -
