Android/AnalyzingCrashDumps
Android produces a crash dump in the system log. This can be used to get at least an idea of where something crashed. Here's what a crash dump looks like:
I/DEBUG (20696): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG (20696): Build fingerprint: 'Samsung/SGH-I897/SGH-I897/SGH-I897:2.2/FROYO/UCJI6:user/release-keys' I/DEBUG (20696): pid: 21148, tid: 21148 >>> /data/data/org.mozilla.fennec/plugin-container <<< I/DEBUG (20696): signal 11 (SIGSEGV), fault addr 00000000 I/DEBUG (20696): r0 00003860 r1 831175de r2 00008a6c r3 831174f1 I/DEBUG (20696): r4 835366ac r5 00000000 r6 411020c8 r7 00000000 I/DEBUG (20696): r8 00000000 r9 00000000 10 00000000 fp 00000000 I/DEBUG (20696): ip 83536bc0 sp be8bdeb8 lr 82bb380f pc 82bb3932 cpsr a0000030 I/DEBUG (20696): d0 6472656767756265 d1 00000002000400ff I/DEBUG (20696): d2 ffffffff000000ff d3 00000000ffffffff I/DEBUG (20696): d4 636974617473206d d5 74642f726f746320 I/DEBUG (20696): d6 656c6966203a726f d7 2e2f2e2e2f2e2e20 I/DEBUG (20696): d8 0000000000000000 d9 0000000000000000 I/DEBUG (20696): d10 0000000000000000 d11 0000000000000000 I/DEBUG (20696): d12 0000000000000000 d13 0000000000000000 I/DEBUG (20696): d14 0000000000000000 d15 0000000000000000 I/DEBUG (20696): d16 0000000000000000 d17 0000000000000000 I/DEBUG (20696): d18 0000000000000000 d19 0000000000000000 I/DEBUG (20696): d20 0000000000000000 d21 0000000000000000 I/DEBUG (20696): d22 0000000000000000 d23 0000000000000000 I/DEBUG (20696): d24 0000000000000000 d25 0000000000000000 I/DEBUG (20696): d26 0000000000000000 d27 0000000000000000 I/DEBUG (20696): d28 0000000000000000 d29 0000000000000000 I/DEBUG (20696): d30 0000000000000000 d31 0000000000000000 I/DEBUG (20696): scr 00000000 I/DEBUG (20696): I/DEBUG (20696): #00 pc 00bb3932 /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): #01 lr 82bb380f /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): I/DEBUG (20696): code around pc: I/DEBUG (20696): 82bb3910 601a3201 3514ae0a 000cf106 fb90f140 I/DEBUG (20696): 82bb3920 f1404630 a813fb8d fb8af140 f140a816 I/DEBUG (20696): 82bb3930 6829fb87 2900af19 af73f47f 46399806 I/DEBUG (20696): 82bb3940 fcc8f0a5 26249c19 5b08f854 4605fb06 I/DEBUG (20696): 82bb3950 f104e007 f140000c 4620fb73 fb70f140 I/DEBUG (20696): I/DEBUG (20696): code around lr: I/DEBUG (20696): 82bb37ec 50e54628 fc44f0a0 49694b68 58e32204 I/DEBUG (20696): 82bb37fc 90061861 f840a81a f1333d04 f65efdaf I/DEBUG (20696): 82bb380c 4b64cd08 930718e3 18e34b63 46059308 I/DEBUG (20696): 82bb381c 90054862 aa16e087 46109203 f667ae0a I/DEBUG (20696): 82bb382c f10dd82d 46600c4c f8cd6869 f667c010 I/DEBUG (20696): I/DEBUG (20696): stack: I/DEBUG (20696): be8bde78 835366ac /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bde7c 82ce737f /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bde80 00040011 I/DEBUG (20696): be8bde84 00000018 I/DEBUG (20696): be8bde88 00000000 I/DEBUG (20696): be8bde8c 41113500 I/DEBUG (20696): be8bde90 835366ac /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bde94 411020c8 I/DEBUG (20696): be8bde98 be8bdf1c [stack] I/DEBUG (20696): be8bde9c 00000004 I/DEBUG (20696): be8bdea0 41115188 I/DEBUG (20696): be8bdea4 835366ac /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdea8 41115188 I/DEBUG (20696): be8bdeac 411020c8 I/DEBUG (20696): be8bdeb0 df002777 I/DEBUG (20696): be8bdeb4 e3a070ad I/DEBUG (20696): #00 be8bdeb8 000000c1 I/DEBUG (20696): be8bdebc 00000304 I/DEBUG (20696): be8bdec0 00000002 I/DEBUG (20696): be8bdec4 00000000 I/DEBUG (20696): be8bdec8 00000001 I/DEBUG (20696): be8bdecc 00003860 I/DEBUG (20696): be8bded0 41113500 I/DEBUG (20696): be8bded4 831174e0 /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bded8 831174f1 /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdedc 8020d7ad /data/data/org.mozilla.fennec/cache/libnspr4.so I/DEBUG (20696): be8bdee0 00000001 I/DEBUG (20696): be8bdee4 835366ac /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdee8 831175de /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdeec 8020d7ad /data/data/org.mozilla.fennec/cache/libnspr4.so I/DEBUG (20696): be8bdef0 835366ac /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdef4 82ce69ef /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): be8bdef8 41115324 I/DEBUG (20696): be8bdefc 831175de /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): dumpmesg > /data/log/dumpstate_app_native.log
There's lots of data here, but to start with, the PC (program counter) and LR (return address) are the most useful. LR might not be valid; you'll have to see if it makes sense, but it generally is on ARM since there's plenty of registers to go around.
Even though these two addresses appear in the register list, scrolling down to this section:
I/DEBUG (20696): #00 pc 00bb3932 /data/data/org.mozilla.fennec/cache/libxul.so I/DEBUG (20696): #01 lr 82bb380f /data/data/org.mozilla.fennec/cache/libxul.so
gives you some more information. PC was listed as 82bb3932 originally, but is 00bb3932 here. The dumper helpfully stripped the base relocation address of the library, which is handy.
On your desktop, you can now do something like:
% arm-eabi-objdump -d -l --start-address=0x00bb3920 --stop-address=0x00bb3950 bin/libxul.so \ | arm-eabi-c++filt
bin/libxul.so: file format elf32-littlearm Disassembly of section .text: 00bb3920 <mozilla::dom::ContentChild::Init(MessageLoop*, int, IPC::Channel*)+0x1a0>: ~nsACString_internal(): /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../dist/include/nsTSubstring.h:113 bb3920: 000c lsls r4, r1, #0 bb3922: f140 fb91 bl cf4048 <nsACString_internal::Finalize()> /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../../mozilla-central/dom/ipc/ContentChild.cpp:256 bb3926: 4630 mov r0, r6 bb3928: f140 fb8e bl cf4048 <nsACString_internal::Finalize()> bb392c: a813 add r0, sp, #76 bb392e: f140 fb8b bl cf4048 <nsACString_internal::Finalize()> bb3932: a816 add r0, sp, #88 bb3934: f140 fb88 bl cf4048 <nsACString_internal::Finalize()> mozilla::dom::ContentChild::Init(MessageLoop*, int, IPC::Channel*)(): bb3938: 6829 ldr r1, [r5, #0] bb393a: af19 add r7, sp, #100 bb393c: 2900 cmp r1, #0 bb393e: f47f af73 bne.w bb3828 <mozilla::dom::ContentChild::Init(MessageLoop*, int, IPC::Channel*)+0xa8> /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../../mozilla-central/dom/ipc/ContentChild.cpp:264 bb3942: 9805 ldr r0, [sp, #20] bb3944: 4639 mov r1, r7 bb3946: f0a5 fcc9 bl c592dc <mozilla::dom::PCrashReporterChild::SendAddLibraryMappings(InfallibleTArray<mozilla::dom::Mapping> const&)> nsTArray_base<nsTArrayInfallibleAllocator>::Length() const(): /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../dist/include/nsTArray.h:139 bb394a: 9c19 ldr r4, [sp, #100] nsTArray<mozilla::dom::Mapping, nsTArrayInfallibleAllocator>::DestructRange(unsigned int, unsigned int)(): /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../dist/include/nsTArray.h:1104 bb394c: 2624 movs r6, #36 nsTArray_base<nsTArrayInfallibleAllocator>::Length() const(): /cygdrive/c/proj/m2/fennec-android/dom/ipc/../../dist/include/nsTArray.h:139 bb394e: f854 5b08 ldr.w r5, [r4], #8
(using the tools in the SDK prebuilt tools dir, though any android toolchain should really work).
You can repeat the same process for the LR value, though you'll have to strip the library location (in this case, 0x82000000) manually; same for any of the other stack addresses.
A brief note about ARM addresses: ARM instructions can be either normal/ARM (4-byte) or Thumb (2-byte). The above example uses Thumb instructions, and objdump recognizes them as such. You may see a lr value that has the high bit set -- this indicates that the return is supposed to take place to the Thumb instruction set. Simply strip off that bit to get the actual address -- for example, 0x....f would become 0x....e and 0x....1 would become 0x....0. If you don't, objdump will happily decode nonsensical instructions from the unaligned addresses.