How to use addr2line

[ezmora]

After giving up on debugging with gdb, and following the
reccomendations of others in this forum, I'd like to use addr2line in
order to spot the code which terminates my program.
So I type in the following:
[NDK DIR]/prebuilt/windows/arm-eabi-4.4.0/bin/arm-eabi-addr2line.exe -
C -f -e obj/local/armeabi/libmyLib.so 451ab108

But what I get is:
??
??:0

Any ideas what I'm doing wrong?

Some info:
1. Using Cygwin
2. Windows 7
3. Emulator
4. Stack trace (partial):
01-12 07:49:00.211: INFO/DEBUG(31): Build fingerprint: 'generic/sdk/
generic/:2.2/FRF91/43546:eng/test-keys'
01-12 07:49:00.211: INFO/DEBUG(31): pid: 455, tid: 462 >>> my.dir<<<
01-12 07:49:00.211: INFO/DEBUG(31): signal 11 (SIGSEGV), fault addr
deadbaad
01-12 07:49:00.221: INFO/DEBUG(31): r0 00000000 r1 0000000c r2
00000027 r3 00000000
01-12 07:49:00.221: INFO/DEBUG(31): r4 00000000 r5 deadbaad r6
00001728 r7 00000001
01-12 07:49:00.221: INFO/DEBUG(31): r8 00100000 r9 8090993d 10
450ac000 fp 451ab18c
01-12 07:49:00.221: INFO/DEBUG(31): ip ffffffff sp 451ab108 lr
afd154c5 pc afd11dc4 cpsr 40000030
01-12 07:49:00.371: INFO/DEBUG(31): #00 pc 00011dc4 /system/
lib/libc.so
01-12 07:49:00.381: INFO/DEBUG(31): #01 pc 0000be1c /system/
lib/libc.so
01-12 07:49:00.381: INFO/DEBUG(31): code around pc:
01-12 07:49:00.381: INFO/DEBUG(31): afd11da4 1c2bd00b 2d00682d
e026d1fb 2b0068db
01-12 07:49:00.381: INFO/DEBUG(31): afd11db4 4e17d003 51a02001
4d164798 24002227
01-12 07:49:00.381: INFO/DEBUG(31): afd11dc4 f7fb702a 2106ee14
ef10f7fc 05592380
01-12 07:49:00.381: INFO/DEBUG(31): afd11dd4 6091aa01 1c116054
94012006 eab6f7fc
01-12 07:49:00.381: INFO/DEBUG(31): afd11de4 2200a905 f7fc2002
f7fbeac2 2106ee00
01-12 07:49:00.381: INFO/DEBUG(31): code around lr:
01-12 07:49:00.381: INFO/DEBUG(31): afd154a4 b0834a0d 589c447b
26009001 686768a5
01-12 07:49:00.391: INFO/DEBUG(31): afd154b4 220ce008 2b005eab
1c28d003 47889901
01-12 07:49:00.391: INFO/DEBUG(31): afd154c4 35544306 d5f43f01
2c006824 b003d1ee
01-12 07:49:00.391: INFO/DEBUG(31): afd154d4 bdf01c30 0002ae7c
000000d4 1c0fb5f0
01-12 07:49:00.391: INFO/DEBUG(31): afd154e4 43551c3d a904b087
1c16ac01 604d9004
01-12 07:49:00.391: INFO/DEBUG(31): stack:
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0c8 00000015
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0cc afd1453b /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0d0 afd40498 /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0d4 afd41b6c /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0d8 00000000
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0dc afd154c5 /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0e0 000013fc
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0e4 afd1450d /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0e8 00100000 [heap]
01-12 07:49:00.391: INFO/DEBUG(31): 451ab0ec afd40328 /system/
lib/libc.so
01-12 07:49:00.456: INFO/DEBUG(31): 451ab0f0 00000000
01-12 07:49:00.456: INFO/DEBUG(31): 451ab0f4 00001728
01-12 07:49:00.456: INFO/DEBUG(31): 451ab0f8 00000001
01-12 07:49:00.456: INFO/DEBUG(31): 451ab0fc afd147ab /system/
lib/libc.so
01-12 07:49:00.456: INFO/DEBUG(31): 451ab100 df002777
01-12 07:49:00.456: INFO/DEBUG(31): 451ab104 e3a070ad
01-12 07:49:00.456: INFO/DEBUG(31): #00 451ab108 80939788 /data/data/
my.dir/lib/libmyLib.so
01-12 07:49:00.461: INFO/DEBUG(31): 451ab10c 00000002
01-12 07:49:00.461: INFO/DEBUG(31): 451ab110 afd418dc /system/
lib/libc.so
01-12 07:49:00.461: INFO/DEBUG(31): 451ab114 afd10510 /system/
lib/libc.so
01-12 07:49:00.461: INFO/DEBUG(31): 451ab118 afd40328 /system/
lib/libc.so


Thanks,
Eyal

[alan]

the following command works for me:
arm-linux-androideabi-addr2line.exe -e <SO_NAME> -i -f -C -s
these are the addresses that you should be using:

01-12 07:49:00.371: INFO/DEBUG(31): #00 pc 00011dc4 /system/
lib/libc.so
01-12 07:49:00.381: INFO/DEBUG(31): #01 pc 0000be1c /system/
lib/libc.so

"451ab108" is a memory address not an offset into your library. The
above crash is inside libc.so, try to download libc.so from your
device and run addr2line on that

[Phil Endecott]

On Jan 12, 8:22 am, ezmora <eyalzm...@gmail.com> wrote:

> After giving up on debugging with gdb, and following the
> reccomendations of others in this forum, I'd like to use addr2line in
> order to spot the code which terminates my program.
> So I type in the following:
> [NDK DIR]/prebuilt/windows/arm-eabi-4.4.0/bin/arm-eabi-addr2line.exe -
> C -f -e obj/local/armeabi/libmyLib.so 451ab108

You need to put 0x in front of the hex address, and you need to make
sure it is an offset into the library, not an absolute address.

[eyal zmora]

Thank you both Alan & Phil.

I will give it a shot.

 

A more general question: 

If "#00 451ab108  80939788  /data/data/my.dir/lib/libmyLib.so"  is a memory address (and not an offset into my library),

how does the stack trace help me spot where in the code the problem is? 

 

Thanks,

Eyal

2011/1/12 Phil Endecott <spam_fro...@chezphil.org>

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

[İsmail Dönmez]

Hi;

On Wed, Jan 12, 2011 at 4:55 PM, eyal zmora <eyal...@gmail.com> wrote:

Thank you both Alan & Phil.

I will give it a shot.

 

A more general question: 

If "#00 451ab108  80939788  /data/data/my.dir/lib/libmyLib.so"  is a memory address (and not an offset into my library),

how does the stack trace help me spot where in the code the problem is? 

I am wondering the same thing over here :) There must be a way to know the load address of libmtLib.so somehow so one could do

offset = memory_adress - load_adresss

Regards,

ismail

 

[Mike Dodd]

01-12 07:49:00.371: INFO/DEBUG(31):          #00  pc 00011dc4  /system/
lib/libc.so
01-12 07:49:00.381: INFO/DEBUG(31):          #01  pc 0000be1c  /system/
lib/libc.so

Those are relative addresses already.

01-12 07:49:00.391: INFO/DEBUG(31):     451ab0cc  afd1453b  /system/
lib/libc.so
01-12 07:49:00.391: INFO/DEBUG(31):     451ab0d0  afd40498  /system/
lib/libc.so

The first value (e.g., 451ab0cc) is the address on the stack itself -- this won't ever correspond to anything in your library. The second value is the contents of the stack at that address, which can correspond to an address in your library. Or they might not be code addresses -- the stack can contain real return addresses, pointers to data, or random numbers that map to code just by coincidence.

[eyal zmora]

This brings me back to my previous question:

How can I use the native stack trace to locate the part of code which terminates the application? Knowing the address on the stack itself isn't much of a help...

 

Also, what is:  "#00  pc 00011dc4  /system/lib/libc.so" ?

2011/1/13 Mike Dodd <md...@android.com>

[Mike Dodd]

That first line (#00 pc ...) is what crashed. In the stack trace below, it means that something in libc.so at relative address 11dc4 crashed. You should be able to use addr2line to map that to a symbol.

The next address (be1c in libc.so) should be the calling function.

[alan]

I think you are confusing the difference between the stack (an area of
memory which holds local variables and other stuff) and a stack trace
(a history of the function calls made by your program). Line by line
the crash log is structured as follows:

** pid: 455, tid: 462 >>> my.dir<<<
the id of the process that crashed
** signal 11 (SIGSEGV), fault addr deadbaad
why the process crashed (segmentation fault) and the address that
caused the fault (deadbaad and deadoddd are special addresses in
android, as far as i can remember baad means an attempt to free
invalid memory (or possibly access, search this group for details),
oddd means a corrupted stack)
** r0 00000000 r1 0000000c r2 00000027 r3 00000000
** r4 00000000 r5 deadbaad r6 00001728 r7 00000001
** r8 00100000 r9 8090993d 10 450ac000 fp 451ab18c
** ip ffffffff sp 451ab108 lr afd154c5 pc afd11dc4 cpsr 40000030
the current values of the various cpu registers, look for an arm
assembly tutorial for the meaining of these registers, the important
ones are "lr" which is the address of the code your current function
will return to, "pc" is the address of the code currently being
executed.
** #00 pc 00011dc4 /system/lib/libc.so
** #01 pc 0000be1c /system/lib/libc.so
this is the stack trace, the crash occured at offset 11dc4 in libc.so
which was called from be1c in libc.so. I have noticed that seg fault
stack traces are not always complete on android, probabaly this is the
case here as the libc functions were most likely called from somewhere
else.
** code around pc:
** afd11da4 1c2bd00b 2d00682d e026d1fb 2b0068db
** afd11db4 4e17d003 51a02001 4d164798 24002227
** afd11dc4 f7fb702a 2106ee14 ef10f7fc 05592380
** afd11dd4 6091aa01 1c116054 94012006 eab6f7fc
** afd11de4 2200a905 f7fc2002 f7fbeac2 2106ee00
this is the assembly code currently being executed
** code around lr:
** afd154a4 b0834a0d 589c447b 26009001 686768a5
** afd154b4 220ce008 2b005eab 1c28d003 47889901
** afd154c4 35544306 d5f43f01 2c006824 b003d1ee
** afd154d4 bdf01c30 0002ae7c 000000d4 1c0fb5f0
** afd154e4 43551c3d a904b087 1c16ac01 604d9004
this is the assembly code that called the function that crashed
** stack:
** 451ab0c8 00000015
** 451ab0cc afd1453b /system/lib/libc.so
** 451ab0d0 afd40498 /system/lib/libc.so
** 451ab0d4 afd41b6c /system/lib/libc.so
** 451ab0d8 00000000
** .....
this is a dump of the contents of the stack, the values are: address
and value. If the value could be an address in a library then the name
of that library will be printed after it.

On Jan 13, 7:40 am, Mike Dodd <md...@android.com> wrote:
> That first line (#00 pc ...) is what crashed. In the stack trace below, it
> means that something in libc.so at relative address 11dc4 crashed. You
> should be able to use addr2line to map that to a symbol.
>
> The next address (be1c in libc.so) should be the calling function.
>

> On Wed, Jan 12, 2011 at 10:29 PM, eyal zmora <eyalzm...@gmail.com> wrote:
> > This brings me back to my previous question:
> > How can I use the native stack trace to locate the part of code which
> > terminates the application? Knowing the address on the stack itself isn't
> > much of a help...
>

> > Also, what is:  "*#00  pc* 00011dc4  /system/lib/libc.so" ?

>
> > 2011/1/13 Mike Dodd <md...@android.com>
>
> >>  01-12 07:49:00.371: INFO/DEBUG(31):          #00  pc 00011dc4  /system/
> >>> lib/libc.so
> >>> 01-12 07:49:00.381: INFO/DEBUG(31):          #01  pc 0000be1c  /system/
> >>> lib/libc.so
>
> >> Those are relative addresses already.
>
> >>  01-12 07:49:00.391: INFO/DEBUG(31):     451ab0cc  afd1453b  /system/
> >>> lib/libc.so
> >>> 01-12 07:49:00.391: INFO/DEBUG(31):     451ab0d0  afd40498  /system/
> >>> lib/libc.so
>
> >> The first value (e.g., 451ab0cc) is the address on the stack itself --
> >> this won't ever correspond to anything in your library. The second value is
> >> the contents of the stack at that address, which can correspond to an
> >> address in your library. Or they might not be code addresses -- the stack
> >> can contain real return addresses, pointers to data, or random numbers that
> >> map to code just by coincidence.
>

> >>> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/android-ndk?hl=en.
>
> >> --
> >> 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<android-ndk%2Bunsu...@googlegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/android-ndk?hl=en.
>
> >  --
> > 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<android-ndk%2Bunsu...@googlegroups.com>
> > .