[Webkit-unassigned] [Bug 85076] ARM JIT causes segmentation fault on javascript-heavy pages

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue May 1 15:33:23 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=85076





--- Comment #13 from Daniel Drake <dsd at laptop.org>  2012-05-01 15:33:23 PST ---
Working from home today, with a different laptop.
So not using the same trace as earlier. Lets start over with a new crash.

(gdb) bt
#0  0x000013e4 in ?? ()
#1  0x499fe5dc in ?? ()
#2  0x499fe5dc in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info registers
r0             0x4996e240    1234625088
r1             0xfffffffb    4294967291
r2             0x4996e240    1234625088
r3             0xfffffffb    4294967291
r4             0x47626688    1197631112
r5             0x1d2    466
r6             0x47626588    1197630856
r7             0x5357c57c    1398261116
r8             0x41d9f3e4    1104802788
r9             0x47626570    1197630832
r10            0x45a67400    1168536576
r11            0x41f55058    1106595928
r12            0x4c1d0ab0    1276971696
sp             0xbe8aed78    0xbe8aed78
lr             0x499fe5dc    1235215836
pc             0x13e4    0x13e4
cpsr           0x600f0010    1611595792

Check around the LR area again:
(gdb) x/12i $lr-32
   0x499fe5bc:    mov    r0, sp
   0x499fe5c0:    str    r4, [sp, #3118288]    ; 0x60
   0x499fe5c4:    mov    r8, #408    ; 0x198
   0x499fe5c8:    str    r8, [r4, #-3118288]    ; 0x2c
   0x499fe5cc:    ldr    r3, [pc, #12638680]    ; 0x499fea40
   0x499fe5d0:    str    r4, [r3]
   0x499fe5d4:    ldr    r8, [pc, #12638680]    ; 0x499fea44
   0x499fe5d8:    blx    r8
   0x499fe5dc:    str    r0, [r4, #3118288]    ; 0x70
   0x499fe5e0:    str    r1, [r4, #3118288]    ; 0x74
   0x499fe5e4:    b    0x499fc264
   0x499fe5e8:    b    0x499fe618

Looking carefully at this instruction:
   0x499fe5d4:    ldr    r8, [pc, #12638680]    ; 0x499fea44

Lets try this calculation by hand. PC is always 8 bytes ahead of the current instruction, so pc=0x499fe5d4 + 8.
Then we add 12638680, and we read from that memory location.

0x499fe5d4 + 8 + 12638680 = 0x4a60bfb4 so:

(gdb) x/x 0x4a60bfb4
0x4a60bfb4:    0x00000000
Hmm, unlikely.

But gdb's annotation said 0x499fea44.

After asking around a bit I've been told that the number inside the square brackets is not to be taken literally. It includes flags and other things. However, the address in the annotation can be trusted.

So, lets check the memory at that address.

(gdb) x/x 0x499fea44
0x499fea44:    0x41d9f3e4
(gdb) x/4i 0x41d9f3e4
   0x41d9f3e4 <cti_op_resolve_global>:    str    lr, [sp, #3118288]    ; 0x40
   0x41d9f3e8 <cti_op_resolve_global+4>:    bl    0x41cf4aac
   0x41d9f3ec <cti_op_resolve_global+8>:    
    ldr    lr, [sp, #3118288]    ; 0x40
   0x41d9f3f0 <cti_op_resolve_global+12>:    mov    pc, lr

And lets also recall that r8 was programmed with this address before we branched. Checking back to the original register dump, r8=0x41d9f3e4 which is the same as cti_op_resolve_global. Things are making some sense.

The offset in the str/ldr lr lines of 3118288 is huge of course. Again I think we have to ignore it. I think the offset being used is 0x40, as shown by the comment.

Now lets think about the value of lr. It got set as 0x499fe5dc because of the "blx r8" that we followed earlier. Now almost immediately inside cti_op_resolve_global we call "bl", which will change the value of lr. However, lr does *not* reflect the return location for the "bl 0x41cf4aac" call. This means either:
 1. We crashed before executing the bl inside cti_op_resolve_global (seems impossible), or
 2. We executed the bl inside cti_op_resolve_global, and then restored lr, and returned. (seems likely)

So lets go back to the code pasted at the top of this comment (around 0x499fe5dc), since thats where we're returning to.

   0x499fe5dc:    str    r0, [r4, #3118288]    ; 0x70
   0x499fe5e0:    str    r1, [r4, #3118288]    ; 0x74

Lets see if we executed those instructions:
r4=0x47626688
r4 + 0x70 = 0x476266f8

(gdb) x/x 0x476266f8
0x476266f8:    0x4996e240

That matches the value of r0.

Looking at the "str r1":

(gdb) x/x 0x476266fc
0x476266fc:    0xfffffffb

That matches the value of r1.

So it seems like we have returned and executed these 2 instructions at least. Next is:

   0x499fe5e4:    b    0x499fc264

Lets look:

(gdb) x/12i 0x499fc264
   0x499fc264:    mov    r2, #1
   0x499fc268:    mvn    r7, #0
   0x499fc26c:    ldr    r0, [r4, #3118288]    ; 0x50
   0x499fc270:    ldr    r1, [r4, #3118288]    ; 0x54
   0x499fc274:    cmn    r7, #1
   0x499fc278:    bne    0x499fe5e8
   0x499fc27c:    cmn    r1, #5
   0x499fc280:    bne    0x499fe5e8
   0x499fc284:    ldr    r8, [r0]
   0x499fc288:    ldr    r3, [pc, #28956432]    ; 0x499fca44
   0x499fc28c:    cmp    r8, r3
   0x499fc290:    bne    0x499fe5ec

This code looks odd.
Seems to set r7 to a fixed value and then compare its value against 1?
Looking at register values and memory I'm having trouble convincing myself that this code has run, but it might have.
Anyway, out of time for today unfortunately.


I tried the test webpage that you provided. It doesn't trigger the crash.
Also after a few runs I haven't managed to reproduce the problem where the stub offset is off by 8. Maybe that one was a bad dump.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list