jit crashes fennec with illegal instruction

VERIFIED FIXED

Status

()

--
blocker
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: jmaher, Unassigned)

Tracking

Trunk
ARM
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.

Comment 1

9 years ago
this looks like 83e105e5f0db
(Reporter)

Updated

9 years ago
Blocks: 503439

Comment 2

9 years ago
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

Updated

9 years ago
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.

Comment 6

9 years ago
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)?

Comment 9

9 years ago
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
Created attachment 389065 [details] [diff] [review]
fix

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 11

9 years ago
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
Last Resolved: 9 years ago
Resolution: --- → FIXED

Updated

9 years ago
Duplicate of this bug: 504761
(Reporter)

Comment 14

9 years ago
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.