Closed Bug 503570 Opened 16 years ago Closed 16 years ago

jit crashes fennec with illegal instruction

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
ARM
All
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jmaher, Unassigned)

References

Details

Attachments

(1 file)

fix
1.46 KB, patch
gal
: review+
Details | Diff | Splinter Review
It appears that since 6/30 Fennec is crashing with an "Illegal instruction" on maemo and windows mobile when the jit preferences are set to true. I need to work on a debug build and see if I can get a stack. For reference Fennec is built from m-c.
this looks like 83e105e5f0db
Blocks: 503439
Stack: 0x01ba0f04 > js3250.dll!js_ExecuteTree(JSContext* cx = 0x509418c8, nanojit::Fragment* f = 0x507b85d8, unsigned int& inlineCallCount = 0, VMSideExit** innermostNestedGuardp = 0x00000000) Line: 5170, Byte Offsets: 0x258 C++ 0x1411af2c in js_ExecuteTree: cx->interpState = state->prev; 01562F08 ldr r3, [r4, #0x3C] 01562F0C ldr r1, [r0, #8] JS_ASSERT(lr->exitType != LOOP_EXIT || !lr->calldepth); tm->tracecx = NULL; LeaveTree(*state, lr); R0 = 0x509418c8 R1 = 0x507b85d8 R2 = 0x01ba0ea4 R3 = 0x00000000 R4 = 0x00000000 R5 = 0x50657c00 R6 = 0x507b85d8 R7 = 0x1411af2c R8 = 0x5093ff20 R9 = 0x1411b8dc R10 = 0x505b9080 R11 = 0x1411af08 R12 = 0x1411b8dc Sp = 0x1411aef4 Lr = 0x01562f08 Pc = 0x01562f08 Psr = 0x60000010 cx 0x509418c8 cx->interpState 0x00000000
Severity: critical → blocker
Can we get a URL or the script that is running or something? 6/30 had a merge, would be great if you could build against the tm tree and see if you can narrow the range.
I am narrowing down the range. In the meantime I have some disassembly for maemo: (gdb) info all r0 0x404d3780 1078802304 r1 0x4530cba0 1160825760 r2 0x40201000 1075843072 r3 0x0 0 r4 0x4530cba0 1160825760 r5 0x404d3780 1078802304 r6 0x402dc800 1076742144 r7 0x40289ce0 1076403424 r8 0xbe8b67f8 3196807160 r9 0xbe8b70a8 3196809384 r10 0x402953a0 1076450208 r11 0xbe8b67cc 3196807116 r12 0x4101ee2c 1090645548 sp 0xbe8b67b8 0xbe8b67b8 lr 0x4073b8ac 1081325740 pc 0x4101ee84 0x4101ee84 f0 0 (raw 0x000189880000000000000000) f1 0 (raw 0x000189880000000000000000) f2 0 (raw 0x000189880000000000000000) f3 0 (raw 0x000189880000000000000000) f4 0 (raw 0x000189880000000000000000) f5 0 (raw 0x000189880000000000000000) f6 0 (raw 0x000189880000000000000000) f7 0 (raw 0x000189880000000000000000) fps 0x0 0 cpsr 0x60000010 1610612752 (gdb) disas $pc-128 $pc+128 Dump of assembler code from 0x4101ee04 to 0x4101ef04: 0x4101ee04: tst r10, r10 0x4101ee08: moveq r10, #1 ; 0x1 0x4101ee0c: movne r10, #0 ; 0x0 0x4101ee10: str r10, [r9, #32] 0x4101ee14: cmp r10, #1 ; 0x1 0x4101ee18: bne 0x4101ded0 0x4101ee1c: b 0x4101dee4 0x4101ee20: mov r0, r2 0x4101ee24: mov sp, r11 0x4101ee28: ldmia sp!, {r4, r5, r6, r7, r8, r9, r10, r11, pc} 0x4101ee2c: stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr} 0x4101ee30: mov r11, sp 0x4101ee34: subs sp, sp, #20 ; 0x14 0x4101ee38: str r0, [r11, #-4] 0x4101ee3c: mov r8, r0 0x4101ee40: eor r10, r10, r10 0x4101ee44: str r10, [r11, #-8] 0x4101ee48: ldr r9, [r8] 0x4101ee4c: ldr r6, [r8, #8] 0x4101ee50: ldr r7, [r9, #-8] 0x4101ee54: ldr r10, [r9, #16] 0x4101ee58: ldr r5, [r9, #24] 0x4101ee5c: str r5, [r11, #-16] 0x4101ee60: ldr r4, [r6] 0x4101ee64: tst r4, r4 0x4101ee68: bne 0x4101def8 0x4101ee6c: str r5, [r9, #8] 0x4101ee70: str r5, [r9, #32] 0x4101ee74: ldr r4, [pc, #-3640] ; 0x4101e044 0x4101ee78: str r4, [r9, #40] 0x4101ee7c: ldr r1, [pc, #-3652] ; 0x4101e040 0x4101ee80: mov r0, r5 0x4101ee84: undefined instruction 0xffdc08fd 0x4101ee88: movs r4, #1 ; 0x1 0x4101ee8c: str r4, [r11, #-12] 0x4101ee90: cmp r0, #1 ; 0x1 0x4101ee94: beq 0x4101df0c 0x4101ee98: str r5, [r9, #32] 0x4101ee9c: ldr r4, [pc, #-3688] ; 0x4101e03c 0x4101eea0: str r4, [r9, #40] 0x4101eea4: ldr r1, [pc, #-3700] ; 0x4101e038 0x4101eea8: mov r0, r5 0x4101eeac: undefined instruction 0xffdc08f3 0x4101eeb0: cmp r0, #1 ; 0x1 0x4101eeb4: beq 0x4101df20 0x4101eeb8: str r5, [r9, #32] 0x4101eebc: ldr r4, [pc, #-3728] ; 0x4101e034 0x4101eec0: str r4, [r9, #40] 0x4101eec4: ldr r1, [pc, #-3740] ; 0x4101e030 0x4101eec8: mov r0, r5 0x4101eecc: undefined instruction 0xffdc08eb 0x4101eed0: cmp r0, #1 ; 0x1 0x4101eed4: beq 0x4101df34 0x4101eed8: str r5, [r9, #32] 0x4101eedc: ldr r5, [pc, #-3768] ; 0x4101e02c 0x4101eee0: str r5, [r9, #40] 0x4101eee4: ldr r1, [pc, #-3780] ; 0x4101e028 0x4101eee8: ldr r0, [r11, #-16] 0x4101eeec: undefined instruction 0xffdc08e3 0x4101eef0: mov r5, r0 0x4101eef4: ldr r0, [r11, #-16] 0x4101eef8: cmp r5, #1 ; 0x1 0x4101eefc: beq 0x4101df48 0x4101ef00: str r0, [r9, #32] End of assembler dump.
Awesome bisecting work Mark. Thanks. Do you have access to TM to back out the patch or do you want me to?
Andreas, I'll leave that to you. Thanks
Hmm. I can't conceive any way for my patch to generate that instruction directly. Data will occasionally be inserted into the instruction stream, and these will show up as undefined instructions, but they should always have a branch to jump over them. The 0x*f****** pattern is an SVC instruction, so this could be linked to bug 471585. However, the most significant nibble in this case is also 0xf, which has special meaning and usually completely changes the meaning of the instruction. For example, "BLX Rn" has the form 0xf12fff2*. Can you isolate the function which emits the undefined instruction? --- Which platform are you running on? Can I see /proc/cpu (or equivalent)?
jacob: on the n810: cat /proc/cpuinfo Processor : ARMv6-compatible processor rev 2 (v6l) BogoMIPS : 164.36 Features : swp half thumb fastmult vfp edsp java CPU implementer : 0x41 CPU architecture: 6TEJ CPU variant : 0x0 CPU part : 0xb36 CPU revision : 2 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format : Harvard I size : 32768 I assoc : 4 I line length : 32 I sets : 256 D size : 32768 D assoc : 4 D line length : 32 D sets : 256
Attached patch fix — — Splinter Review
Blah. intptr_t is signed, so when we right shift, it'll get sign-extended. So if the offset is ever negative, we'll end up leaving 0xff in the high byte.. and when it gets or'd, bad things happen. The old BL code did an explicit & 0xffffff when generating the instruction, so didn't hit this.
Comment on attachment 389065 [details] [diff] [review] fix Ouch. Should have seen that. Maybe take out the dead asserts?
Attachment #389065 - Flags: review+
http://hg.mozilla.org/mozilla-central/rev/3555a6324b1a Closing this bug as this particular issue is fixed, though there's a crash further on somewhere during Fennec's startup.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
verified with nightly build 08/13/2009
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: