how to know where the native codes get segment fault?

[Jian Chen]

To the gurus of android NDK,

An application is developed by NDK, which is wrapped by java.
When this application started to run, it got a segment fault.
In the logcat, below message was seed:

07-30 09:52:15.169: INFO/DEBUG(28): Build fingerprint: 'generic/sdk/generic/:2.1-update1/ECLAIR/35983:eng/test-keys'
07-30 09:52:15.169: INFO/DEBUG(28): pid: 224, tid: 232  >>> oms.cj.yap <<<
07-30 09:52:15.169: INFO/DEBUG(28): signal 11 (SIGSEGV), fault addr 5a878004
07-30 09:52:15.169: INFO/DEBUG(28):  r0 00000000  r1 00000001  r2 afe3bb74  r3 5a878000
07-30 09:52:15.169: INFO/DEBUG(28):  r4 afe38e08  r5 afe3b9bc  r6 0000a000  r7 000001b4
07-30 09:52:15.169: INFO/DEBUG(28):  r8 00002174  r9 0000017c  10 000001a0  fp 000002c8
07-30 09:52:15.169: INFO/DEBUG(28):  ip 80b30954  sp 5a743ba8  lr afe0f3b0  pc afe0aea4  cpsr 20000030

It told me a SIGSEGV signal is got and the code address is 5a878004.
But is there a way to know which line of my C codes is the same as 0x5a878004 ?

BTW, there are other message like below, but sound that I can not get any valueful Info from it.
07-30 09:52:15.169: INFO/DEBUG(28):  r0 00000000  r1 00000001  r2 afe3bb74  r3 5a878000
07-30 09:52:15.169: INFO/DEBUG(28):  r4 afe38e08  r5 afe3b9bc  r6 0000a000  r7 000001b4
07-30 09:52:15.169: INFO/DEBUG(28):  r8 00002174  r9 0000017c  10 000001a0  fp 000002c8
07-30 09:52:15.169: INFO/DEBUG(28):  ip 80b30954  sp 5a743ba8  lr afe0f3b0  pc afe0aea4  cpsr 20000030
07-30 09:52:15.289: INFO/DEBUG(28):          #00  pc 0000aea4  /system/lib/libc.so
07-30 09:52:15.289: INFO/DEBUG(28):          #01  pc 00026810  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.289: INFO/DEBUG(28):          #02  pc 00022bde  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.298: INFO/DEBUG(28):          #03  pc 000067ae  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.298: INFO/DEBUG(28):          #04  pc 000067e8  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.298: INFO/DEBUG(28):          #05  pc 00008b50  /data/data/oms.cj.yap/lib/libapplication.so
07-30 09:52:15.308: INFO/DEBUG(28):          #06  pc 00017862  /system/lib/libc.so
07-30 09:52:15.308: INFO/DEBUG(28):          #07  pc 00017c3e  /system/lib/libc.so
07-30 09:52:15.308: INFO/DEBUG(28):          #08  pc 00006548  /data/data/oms.cj.yap/lib/libapplication.so
07-30 09:52:15.308: INFO/DEBUG(28):          #09  pc 0000b39a  /data/data/oms.cj.yap/lib/libapplication.so
07-30 09:52:15.320: INFO/DEBUG(28):          #10  pc 00007e76  /data/data/oms.cj.yap/lib/libapplication.so
07-30 09:52:15.320: INFO/DEBUG(28):          #11  pc 0000a452  /data/data/oms.cj.yap/lib/libapplication.so
07-30 09:52:15.320: INFO/DEBUG(28):          #12  pc 00000c00  /data/data/oms.cj.yap/lib/libsdl_main.so
07-30 09:52:15.330: INFO/DEBUG(28):          #13  pc 0000f1f4  /system/lib/libdvm.so
07-30 09:52:15.330: INFO/DEBUG(28):          #14  pc 00037fcc  /system/lib/libdvm.so
07-30 09:52:15.330: INFO/DEBUG(28):          #15  pc 00031642  /system/lib/libdvm.so
07-30 09:52:15.339: INFO/DEBUG(28):          #16  pc 0003d31c  /system/lib/libdvm.so
07-30 09:52:15.339: INFO/DEBUG(28):          #17  pc 00013f58  /system/lib/libdvm.so
07-30 09:52:15.349: INFO/DEBUG(28):          #18  pc 00019888  /system/lib/libdvm.so
07-30 09:52:15.349: INFO/DEBUG(28):          #19  pc 00018d5c  /system/lib/libdvm.so
07-30 09:52:15.349: INFO/DEBUG(28):          #20  pc 0004d6d0  /system/lib/libdvm.so
07-30 09:52:15.359: INFO/DEBUG(28):          #21  pc 0004d702  /system/lib/libdvm.so
07-30 09:52:15.359: INFO/DEBUG(28):          #22  pc 00041c78  /system/lib/libdvm.so
07-30 09:52:15.359: INFO/DEBUG(28):          #23  pc 00010000  /system/lib/libc.so
07-30 09:52:15.369: INFO/DEBUG(28):          #24  pc 0000fad4  /system/lib/libc.so
07-30 09:52:15.369: INFO/DEBUG(28): code around pc:
07-30 09:52:15.369: INFO/DEBUG(28): afe0ae94 3b081c2b 960619a5 42b3692e e26cd200
07-30 09:52:15.369: INFO/DEBUG(28): afe0aea4 07876858 e268d400 1c012703 270143b9
07-30 09:52:15.378: INFO/DEBUG(28): afe0aeb4 4238185a e0ced000 42386818 43b8d010
07-30 09:52:15.378: INFO/DEBUG(28): code around lr:
07-30 09:52:15.378: INFO/DEBUG(28): afe0f3a0 e1a00005 e3a01001 e1a02004 ebfff980
07-30 09:52:15.378: INFO/DEBUG(28): afe0f3b0 e3500000 1a000001 ea000008 ebfff98a
07-30 09:52:15.378: INFO/DEBUG(28): afe0f3c0 e1a01004 e3a00002 ebfff985 e3500000
07-30 09:52:15.378: INFO/DEBUG(28): stack:
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b68  00000000 
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b6c  acc972ad  /system/lib/egl/libGLES_android.so
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b70  00000000 
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b74  afe0f2c0  /system/lib/libc.so
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b78  80b32988 
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b7c  00000001 
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b80  afe3bb74 
07-30 09:52:15.388: INFO/DEBUG(28):     5a743b84  afe0f3b0  /system/lib/libc.so
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b88  afe38e08  /system/lib/libc.so
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b8c  5a878008 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b90  00000003 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b94  000001b4 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b98  00002174 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743b9c  0000017c 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743ba0  df002777 
07-30 09:52:15.398: INFO/DEBUG(28):     5a743ba4  e3a070ad 
07-30 09:52:15.398: INFO/DEBUG(28): #00 5a743ba8  00000095 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bac  acc95e29  /system/lib/egl/libGLES_android.so
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bb0  00000001 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bb4  00000001 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bb8  80b32984 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bbc  5a743bc4 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bc0  00002bb4 
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bc4  00139790  [heap]
07-30 09:52:15.410: INFO/DEBUG(28):     5a743bc8  80b3279c 
07-30 09:52:15.419: INFO/DEBUG(28):     5a743bcc  000000c4 
07-30 09:52:15.419: INFO/DEBUG(28):     5a743bd0  00000000 
07-30 09:52:15.419: INFO/DEBUG(28):     5a743bd4  0014d280  [heap]
07-30 09:52:15.419: INFO/DEBUG(28):     5a743bd8  00000000 
07-30 09:52:15.419: INFO/DEBUG(28):     5a743bdc  80b26813  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.419: INFO/DEBUG(28): #01 5a743be0  00000328 
07-30 09:52:15.419: INFO/DEBUG(28):     5a743be4  0014d280  [heap]
07-30 09:52:15.419: INFO/DEBUG(28):     5a743be8  80b307e8  /data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.429: INFO/DEBUG(28):     5a743bec  80b327b0 
07-30 09:52:15.429: INFO/DEBUG(28):     5a743bf0  0000020c 
07-30 09:52:15.429: INFO/DEBUG(28):     5a743bf4  80b22be1  /data/data/oms.cj.yap/lib/libsdl.so

Thanks!

[Onur Cinar]

Hi Jian,

Looks like it crashed on the "free" method (/opt/digit/android/main/cupcake/android/bionic/libc/bionic/dlmalloc.c:4396)

You can use addr2line to get the line number and function name from the addresses. For example:

07-30 09:52:15.289: INFO/DEBUG(28):          #00  pc 0000aea4  /system/lib/libc.so
07-30 09:52:15.289: INFO/DEBUG(28):          #01  pc 00026810  /data/data/oms.cj.yap/lib/

libsdl.so

I do addr2line -f -e libc.so 0000aea4, to get the line number for address 0000aea4.

You can repeat the same steps to get other line numbers as well until you find the real bug.

By the way, the the .so file in the lib/armeabi directory is already stripped. So to get the line numbers from your library, you need to use the one in the NDK's out directory.

Regards,

-onur

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

---
www.zdo.com

[Onur Cinar]

Hi,

I just remembered that I had a shell script before to this automatically. I'm attaching it to this e-mail. I hope it is still working with the latest NDK.

You can use it as:

./stack myapp logfile.txt

The output should inlcude the line number and function names for your libraries.

Regards,

-onur

---
www.zdo.com

[Raffaello Brondi]

hi,

You could use ndk-gdb that comes with ndk r4 but take care about the requirements(docs/NDK-GDB.txt).

There is also a python script that tells you where the segmentation fault happened.
You could find it here

--

[Jack]

You could use addr2line tool to trace where your code crashes.
addr2line -f -e ~/NDK/android-ndk-r4/build/platforms/android-8/arch-
arm/usr/lib/libc.so 0x0000aea4

which should return something like:
free
/opt/digit/android/main/cupcake/android/bionic/libc/bionic/dlmalloc.c:
4396


for more information: http://stackoverflow.com/questions/2314273/get-function-names-from-call-stack

07-30 09:52:15.289: INFO/DEBUG(28): #00 pc 0000aea4
/system/lib/libc.so
07-30 09:52:15.289: INFO/DEBUG(28): #01 pc 00026810
/data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.289: INFO/DEBUG(28): #02 pc 00022bde
/data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.298: INFO/DEBUG(28): #03 pc 000067ae
/data/data/oms.cj.yap/lib/libsdl.so
07-30 09:52:15.298: INFO/DEBUG(28): #04 pc 000067e8
/data/data/oms.cj.yap/lib/libsdl.so

[Nicklas Ansman]

I'm assuming that you've tried to use "ndk-gdb" and this was
unsuccessful (it seems to be broken for many people, including me)

What you can do is to disassemble the .so file and see where in the
file it was.

To do this execute the following:
$NDK_ROOT/build/prebuilt/HOST/arm-eabi-4.2.1/bin/arm-eabi-objdump -dR /
PATH/TO/.SO/FILE > tmp
Where "HOST" is the folder in the prebuilt folder, this differs on
each system.

If you look at your debug info you'll se a bunch of there lines:

07-30 09:52:15.289: INFO/DEBUG(28): #00 pc 0000aea4
/system/lib/libc.so
07-30 09:52:15.289: INFO/DEBUG(28): #01 pc 00026810
/data/data/oms.cj.yap/lib/libsdl.so

These are called the stack trace, 'pc' stands for program counter
which is the register that keeps track of what line of assembly that
is currently being executed.
Look for the last entry which was in your file (I'm assuming that
"libapplication" is your file so the last entry with that file would
be 07-30 09:52:15.298: INFO/DEBUG(28): #05 pc 00008b50 /data/data/
oms.cj.yap/lib/libapplication.so)

Now you know that the last function the program ran (last function in
your application at least) contains the address #00008b50.
Now search for 08b50 in the tmp-file (the first three zeros are
omitted), on that line a call should be made to an external
subroutine, now scroll up until you see a function name. Now you know
which function in your program that crashed.

As an example here's a snippet of libc.so:
000188ac <__assert>:
188ac: b530 push {r4, r5, lr}
188ae: 4c07 ldr r4, [pc, #28] (188cc <__assert+0x20>)
188b0: 1c03 adds r3, r0, #0
188b2: 4807 ldr r0, [pc, #28] (188d0 <__assert+0x24>)
188b4: 447c add r4, pc
188b6: 4d07 ldr r5, [pc, #28] (188d4 <__assert+0x28>)
188b8: 5820 ldr r0, [r4, r0]
188ba: b083 sub sp, #12
188bc: 1964 adds r4, r4, r5
188be: 9100 str r1, [sp, #0]
188c0: 30a8 adds r0, #168
188c2: 1c21 adds r1, r4, #0
188c4: f7fc f916 bl 14af4 <fprintf>
188c8: f7f9 fa4c bl 11d64 <abort>
188cc: 7a70 ldrb r0, [r6, #9]
188ce: 0002 lsls r2, r0, #0
188d0: 00a0 lsls r0, r4, #2
188d2: 0000 lsls r0, r0, #0
188d4: 6d0e ldr r6, [r1, #80]
188d6: ffff b5f0 vsli.64 <illegal reg q13.5>, q8, #63

The stack trace was:
#0 pc: #00011d94
#1 pc: #000188c8
In this example the PC we're looking for was #1 (let's pretend that
the first one was in a different file) and the pc at this line is
#000188c8 which means the last call that was made was to "abort" from
the function "__assert", I know this because on the line starting with
"188c8" this is:
188c8: f7f9 fa4c bl 11d64 <abort>

This tells me that abort was called and if a scroll up I see "000188ac
<__assert>:" which tells me that the function in libc.so that I'm
looking for is called __assert.

This usually is enough to figure out what has happened

I hope this helps a bit :)

// Nicklas

[andrej sarkic]

This script can be very useful, too:

https://code.google.com/p/android-ndk-stacktrace-analyzer/

> ...
>
> read more »

[Jian Chen]

Thanks for all gurus' excellent answers.

Special to Onur, in ur previous article in NDK mailing list, a tip is posted to state another way to tranlate 0x like addr to funtion name.
It is a very cool solution since a mixed of address and src lines are given directly in Eclipse.
Here is the original post,

Onur Cinar <onur....@gmail.com> Jun 16 02:30PM -0700 ^
 
In addition to the addr2line tool, if you are using Eclipse as your
IDE for NDK, then you can configure it to automatically do that for
you also.
 
In order to do that:
 
              - Set Project - Settings - C/C++ General - Paths and Symbols - Output
              Location to the $(ANDROID_NDK)/out/apps/dtme/armeabi

 
- Set Project - Settings - C/C++ Build - Settings - Binary Parsers to
have GNU ELF Parser enabled. You can also have the paths set to use
the addr2line and c++filt from the NDK package as well. On Linux, I
didn't have to, but on Windows it makes sense.
 
On C/C++ perspective, you will see the Binary group with the output
dynamic libraries, and if you open them it will give you a mixed
output with the address and the actual content of the line. It is
easier to use most of the time.
 
Regards,
 
-onur

I followed its steps, but the problem is that a mixed of address and src lines are not given when I clicked the Binary Groups.
Instead, a blank page is given. Attach a jpeg FYI.
My question is that shall I install other eclipse plugins to get it displayed correctly?