Comment 18 for bug 1081417

For the record, this is what happens:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
Missing separate debuginfos, use: zypper install cpp47-debuginfo-4.7.1_20120723-1.3.1.armv7hl
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x002a8a44 in ?? ()
#2 0x0027b260 in ?? ()
#3 0x001739a0 in ?? ()
#4 0x00173a40 in ?? ()
#5 0x00175638 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) up
#1 0x002a8a44 in ?? ()
(gdb) x /2i $pc-4
   0x2a8a40: bl 0x2a872c
   0x2a8a44: cmp r0, #0

Looking at the stack frame, I would assume that we never got into the function at 0x21872c:

(gdb) x /2i 0x2a872c
   0x2a872c: cmp r1, r0
   0x2a8730: push {r3, r4, r5, r6, r7, r8, r9, r10, r11, lr}

(gdb) x /10x $r13
0xbeffec70: 0xb5849600 0x00000001 0x00000000 0x00000000
0xbeffec80: 0xffffffff 0xffffffff 0x00111b08 0x00000002
0xbeffec90: 0x00000005 0x0027b260

As you can see, the value of "lr" on the stack frame is still from the previous function. So either we never executed the function at 0x2a872c or we returned from it with r13 restored, but pc=0. Which again is unlikely, given the data further down the stack:

(gdb) x /10x $r13-0x40
0xbeffec30: 0x00000001 0xb57bce60 0xb5849600 0x00000000
0xbeffec40: 0xb58493e0 0x001187f8 0x00000000 0x00000000
0xbeffec50: 0x00000000 0x00000000

So my guess would be that for some reason the bl jumps to NULL instead of 0x2a872c where it really should have gone.