How to map the exception to the source code

[Jerry Yin]

Hi There,

I have the following exception from the logcat. I tried to use the ndk-stack to catch the exception. It only displays the libc.so code. However, I want to map the exception address 44b2d7fc  81ef932f to my own code at /data/data/com.sample.apps/lib/libmodule1.so. The libmodule1.so is a dynamically loaded library by dlopen(). I tried to use add2line and it does not work. I used nm and objdump to dump the symbols and found the address is much smaller than the exception address. Could someone tell me how to map the address to source code?

thanks
Jerry

adb logcat |ndk-stack -sym ~$PROJECT/obj/local/armeabi
********** Crash dump: **********
Build fingerprint: 'generic/polaris/polaris:2.3.4/GINGERBREAD/eng.user.20120328.104830:eng/'
pid: 2063, tid: 2075  >>> com.sipcore.freeswitch:remote <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
Crash dump is completed

********** Crash dump: **********
Build fingerprint: 'generic/polaris/polaris:2.3.4/GINGERBREAD/eng.user.20120328.104830:eng/'
pid: 2207, tid: 2219  >>> com.sipcore.freeswitch:remote <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
Stack frame #00  pc 00015628  /system/lib/libc.so: Routine tmalloc_small in bionic/libc/bionic/dlmalloc.c:3896
Stack frame #01  pc 0001ba88  /system/lib/libc.so: Routine exponent in bionic/libc/stdio/vfprintf.c:1268



I/pbxShell( 2191): 2012-03-29 18:
I/DEBUG   ( 2078): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 2078): Build fingerprint: 'generic/polaris/polaris:2.3.4/GINGERBREAD/eng.user.20120328.104830:eng/'
I/DEBUG   ( 2078): pid: 2207, tid: 2219  >>> com.sipcore.freeswitch:remote <<<
I/DEBUG   ( 2078): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
I/DEBUG   ( 2078):  r0 00000008  r1 44b2d8cf  r2 80808080  r3 00000000
I/DEBUG   ( 2078):  r4 44b2dca8  r5 00000002  r6 00000000  r7 44b2d83c
I/DEBUG   ( 2078):  r8 44b2da60  r9 00000008  10 00000001  fp 44b2dcac
I/DEBUG   ( 2078):  ip 00000073  sp 44b2d7d0  lr afd1ba8b  pc afd15628  cpsr 60000010
I/DEBUG   ( 2078):  d0  3d65756c61762032  d1  20797265766f6337
I/DEBUG   ( 2078):  d2  7369786520746f35  d3  20345f7273207330
I/DEBUG   ( 2078):  d4  6f20656d616e7473  d5  75615f706973206e
I/DEBUG   ( 2078):  d6  616369746e656874  d7  6f6828206e6f6974
I/DEBUG   ( 2078):  d8  0000000000000000  d9  0000000000000000
I/DEBUG   ( 2078):  d10 0000000000000000  d11 0000000000000000
I/DEBUG   ( 2078):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 2078):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 2078):  d16 415d010020000000  d17 3fe0000000000000
I/DEBUG   ( 2078):  d18 42eccefa43de3400  d19 3fbc71c71c71c71c
I/DEBUG   ( 2078):  d20 4008000000000000  d21 3fd99a27ad32ddf5
I/DEBUG   ( 2078):  d22 3fd24998d6307188  d23 3fcc7288e957b53b
I/DEBUG   ( 2078):  d24 3fc74721cad6b0ed  d25 3fc39a09d078c69f
I/DEBUG   ( 2078):  d26 0000000000000000  d27 0000000000000000
I/DEBUG   ( 2078):  d28 0000000000000000  d29 0000000000000000
I/DEBUG   ( 2078):  d30 0000000000000000  d31 0000000000000000
I/DEBUG   ( 2078):  scr 60000012
I/DEBUG   ( 2078):
I/DEBUG   ( 2078):          #00  pc 00015628  /system/lib/libc.so
I/DEBUG   ( 2078):          #01  pc 0001ba88  /system/lib/libc.so
I/DEBUG   ( 2078):
I/DEBUG   ( 2078): code around pc:
I/DEBUG   ( 2078): afd15608 0a00003d e58d2004 e59d2004 e3120003
I/DEBUG   ( 2078): afd15618 1afffff6 e0800003 e3082080 e3482080
I/DEBUG   ( 2078): afd15628 e4901004 e0433000 f5d0f040 e041c3a2
I/DEBUG   ( 2078): afd15638 e00cc002 e1dcc001 04901004 1a000022
I/DEBUG   ( 2078): afd15648 e041c3a2 e00cc002 e1dcc001 04901004
I/DEBUG   ( 2078):
I/DEBUG   ( 2078): code around lr:
I/DEBUG   ( 2078): afd1ba68 b910c014 a018f8dd 9906e00e 0a00ebc9
I/DEBUG   ( 2078): afd1ba78 bfa8458a e007468a f8cd4648 f7f9c014
I/DEBUG   ( 2078): afd1ba88 f8ddeda0 4682c014 f10d2000 465c0ef8
I/DEBUG   ( 2078): afd1ba98 f80e4683 f8cd0c01 e14cb018 46d89709
I/DEBUG   ( 2078): afd1baa8 f0469f07 e00c0610 7ff00000 00021afd
I/DEBUG   ( 2078):
I/DEBUG   ( 2078): stack:
I/DEBUG   ( 2078):     44b2d790  7774656e 
I/DEBUG   ( 2078):     44b2d794  5f6b726f 
I/DEBUG   ( 2078):     44b2d798  74726f70 
I/DEBUG   ( 2078):     44b2d79c  20202020 
I/DEBUG   ( 2078):     44b2d7a0  43524156 
I/DEBUG   ( 2078):     44b2d7a4  28524148 
I/DEBUG   ( 2078):     44b2d7a8  0a2c2936 
I/DEBUG   ( 2078):     44b2d7ac  6e202020 
I/DEBUG   ( 2078):     44b2d7b0  6f777465 
I/DEBUG   ( 2078):     44b2d7b4  695f6b72 
I/DEBUG   ( 2078):     44b2d7b8  20202070 
I/DEBUG   ( 2078):     44b2d7bc  56202020 
I/DEBUG   ( 2078):     44b2d7c0  48435241 
I/DEBUG   ( 2078):     44b2d7c4  32285241 
I/DEBUG   ( 2078):     44b2d7c8  df002777 
I/DEBUG   ( 2078):     44b2d7cc  e3a070ad 
I/DEBUG   ( 2078): #00 44b2d7d0  41455243 
I/DEBUG   ( 2078):     44b2d7d4  54204554 
I/DEBUG   ( 2078): #01 44b2d7d8  454c4241 
I/DEBUG   ( 2078):     44b2d7dc  35373238 
I/DEBUG   ( 2078):     44b2d7e0  30303030 
I/DEBUG   ( 2078):     44b2d7e4  27e4f14f 
I/DEBUG   ( 2078):     44b2d7e8  0a282065 
I/DEBUG   ( 2078):     44b2d7ec  00000073 
I/DEBUG   ( 2078):     44b2d7f0  ffffffff 
I/DEBUG   ( 2078):     44b2d7f4  44b2d83c 
I/DEBUG   ( 2078):     44b2d7f8  44b2d874 
I/DEBUG   ( 2078):     44b2d7fc  81ef932f  /data/data/com.sample.apps/lib/libmodule1.so
I/DEBUG   ( 2078):     44b2d800  00000000 
I/DEBUG   ( 2078):     44b2d804  00000000 
I/DEBUG   ( 2078):     44b2d808  00000005 
I/DEBUG   ( 2078):     44b2d80c  44b2d8cf 
I/DEBUG   ( 2078):     44b2d810  81ef9328  /data/data/com.sample.apps/lib/libmodule1.so
I/DEBUG   ( 2078):     44b2d814  afd4451c 
I/DEBUG   ( 2078):     44b2d818  00000000 
I/DEBUG   ( 2078):     44b2d81c  44b2d8e1 
D/dalvikvm( 1775): GC_EXPLICIT freed 8K, 51% free 2766K/5575K, external 716K/1038K, paused 86ms
I/BootReceiver( 1559): Copying /data/tombstones/tombstone_08 to DropBox (SYSTEM_TOMBSTONE)

[mic _]

You'll have to subtract the base address of where your library is loaded in memory. Typically you can just mask out the top N bits (i.e.  81ef932f  would become  0000932f, or possibly  000f932f since I have no idea about the size of your library).    

/Michael

--
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.

[sip3261]

Hi mic,

Thanks for your response. I tried it does not work. Actually I have
several dynamic libs that are using dlopen() to load into the apps. I
can use the gdb to check the code. Do you know how do I check the base
address of the library?

thanks,
Jerry

On Mar 29, 4:04 pm, mic _ <micol...@gmail.com> wrote:
> You'll have to subtract the base address of where your library is loaded in
> memory. Typically you can just mask out the top N bits (i.e.  81ef932f  would
> become  0000932f, or possibly  000f932f since I have no idea about the size
> of your library).
>
> /Michael
>

[Chris Stratton]

On Thursday, March 29, 2012 5:12:19 PM UTC-4, sip3261 wrote:

Thanks for your response. I tried it does not work. Actually I have
several dynamic libs that are using dlopen() to load into the apps. I
can use the gdb to check the code. Do you know how do I check the base
address of the library?

If you can get in there while it's still running, it's probably easier to look at /proc/pid ##/maps

 

 

[sip3261]

Hi Chris,

That works. I used adb shell and went into the /proc/pid and I cated
the maps. I could find the library base address. It turned out that
the base address was same as what mic said, the top 3 bits of the addr
of the stack:

81e00000-81f11000 r-xp 00000000 b3:0e 73369 /data/data/
com.sample.apps/lib/libmodule1.so
81f11000-81f1b000 rw-p 00111000 b3:0e 73369 /data/data/
com.sample.apps/lib/libmodule1.so

However, I still can't find the symbols in the lib. Then I dumped the
lib and found the address around the exception addr (000f932f) is like
this:

000f9300 r __PRETTY_FUNCTION__.15536
000f930c r __PRETTY_FUNCTION__.15447
000f9318 R module_version

What are these symbols and how do I identify the related source?

thanks again,
Jerry

[mic _]

Those are just strings containing function names (to be used if you e.g. try to use __func__ to print the name of the current function in a log).

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

[Chris Stratton]

On Friday, March 30, 2012 2:25:53 PM UTC-4, sip3261 wrote:

However, I still can't find the symbols in the lib. Then I dumped the
lib and found the address around the exception addr (000f932f) is like
this:

000f9300 r __PRETTY_FUNCTION__.15536
000f930c r __PRETTY_FUNCTION__.15447
000f9318 R module_version 

Use ndk's object dump to dump the symbols, it should be in the code belonging to the last preceding function.  If you want to be sure, use objdump to dissasemble and find the specific instruction and what it is part of.

Some versions of objdump can get confused between arm and thumb code and produce garbage, if you suspect that there are flags to force it to disassemble as one or the other.  A typical example would be if the internals of a function are thumb code, and your address of interest falls in the middle of a what objdump mistakenly thinks is a 32-bit arm instruction.

Also you may have a stripped library object on the device without symbols except those needed for linkage - so you may have to figure it out from the linkages, or re-run with an unstripped library.

This is probably a case of you handing something invalid to a libc function, which then experiences the error.  So your main goal may be to identify which libc function has been invoked, then consider where you use that in your program without validating the parameter.  Doing the same address identification on libc may be productive, if it turns out to be a function used in only a few places.