Comment 30 for bug 1066046

Sorry, think I've wasted a bit of your time.
It looks like I had installed a different webkit build since the crash, and this was affecting the gdb output.

Putting the right build back (the one from which the core was captured), I get different output.

So, stepping back a bit.
lr is still 0x49f0eaf4

The preceding instructions:

   0x49f0ead0: ldr r8, [pc, #26091512] ; 0x49f0ed34
   0x49f0ead4: blx r8
   0x49f0ead8: b 0x49f0d0d0
   0x49f0eadc: mov r0, sp
   0x49f0eae0: str r4, [sp, #3118288] ; 0x60
   0x49f0eae4: ldr r3, [pc, #26091512] ; 0x49f0ed3c
   0x49f0eae8: str r4, [r3]
   0x49f0eaec: ldr r8, [pc, #26091512] ; 0x49f0ed40
   0x49f0eaf0: blx r8
   0x49f0eaf4: b 0x49f0b164

So, value of 0x49f0ed40

(gdb) x/x 0x49f0ed40
0x49f0ed40: 0x41d5d15c

Nothing new until now. But lets look at that code with the right library in place:

   0x41d5d15c <cti_op_get_by_id_proto_fail+8>:
    ldr lr, [sp, #3118288] ; 0x40
   0x41d5d160 <cti_op_get_by_id_proto_fail+12>: mov pc, lr
   0x41d5d164 <cti_op_get_by_id_array_fail>:
    str lr, [sp, #3118288] ; 0x40
   0x41d5d168 <cti_op_get_by_id_array_fail+4>: bl 0x41cae2e8

This looks suspicious. Does it tell you anything?

Just to compare, the previous fallback condition is:
   0x49f0ead0: ldr r8, [pc, #26091512] ; 0x49f0ed34
   0x49f0ead4: blx r8

(gdb) x/x 0x49f0ed34
0x49f0ed34: 0x41d5d1ac
(gdb) x/4i 0x41d5d1ac
   0x41d5d1ac <cti_op_del_by_id+8>: ldr lr, [sp, #3118288] ; 0x40
   0x41d5d1b0 <cti_op_del_by_id+12>: mov pc, lr
   0x41d5d1b4 <cti_op_mul>: str lr, [sp, #3118288] ; 0x40
   0x41d5d1b8 <cti_op_mul+4>: bl 0x41caf998