1068331 - Firefox Nightly 35.0a1 crashes when running mandelbrot-asm.html SIMD path

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Ningxin Hu]

Install Firefox Nightly 35.0a1 (2014-09-16).
Navigate to http://peterjensen.github.io/mandelbrot/js/mandelbrot-asm.html. It is at the version https://github.com/PeterJensen/mandelbrot/commit/ea57ed5a41d789fa8ac932426012a6550f987c7a.
Press 'Start' and then press 'SIMD' button.

What happened:
Firefox will reports "Tab Crashed".

What is expected:
Firefox should be able to run this demo.

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks for the report. Did you activate e10s? (if you're not sure, you can go to the hamburger menu, then Setting, then see if the checkbox 'Enable E10S' is checked)

Alon, does it match what you've seen?

Comment 2

[Ningxin Hu]

I can reproduce this with both e10s on and off.

Comment 3

[Alon Zakai (:azakai)]

Sounds like what I see too. I also see it with or without e10s. Here's my crash

https://crash-stats.mozilla.com/report/index/c7410496-de69-4a90-93b7-a6bc82140916

I thought it was bug 991847 based on the signature, but makes sense it would be SIMD-specific.

I see it on my oldest machine. Perhaps we're doing something wrong for that CPU? I can check exactly which it is when I get home.

Comment 4

[Alon Zakai (:azakai)]

My CPU is "Intel(R) Core(TM)2 Duo CPU T6400", and I'm running 64-bit linux on it.

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

Still can't reproduce the crash, and people around me neither. CC'ing some people who might want to try as well and see if they have an idea and/or can reproduce...

Comment 6

[Douglas Crosher [:dougc]]

Crashes here:
Assertion failure: *def->output() == alloc, at js/src/jit/RegisterAllocator.cpp:212

Comment 7

[James Kitchener (:jkitch)]

Last good revision: 784efb03fa57
First bad revision: 98ea98c8191a
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=784efb
03fa57&tochange=98ea98c8191a

Bug 1051860?

Tested on a Core 2 Duo E8500 - has SSE4.1, but nothing newer.

Comment 8

[James Kitchener (:jkitch)]

(In reply to James Kitchener from comment #7)
> Bug 1051860?
> 

No crash experienced when the patches from bug 1051860 are backed out.

Comment 9

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: 1068331-backout.patch

Thanks for the bisecting! I can actually reproduce in a debug build (which means the issue might be present in the browser as well !). It's indeed due to the float32x4 optimization generation, somehow (?). This patch backs out only the float32x4 opt and solves the issue on both builds. I'll have it reviewed by the end of the day if I can't find the issue beforehand.

Comment 10

[Benjamin Bouvier [:bbouvier] (inactive)]

Attachment: Patch

So after our discussions on IRC, if I understand correctly:
- defineReuseInput X => X must be used at start, other inputs can't be used at start.
- int32x4 doesn't reuse the input, so all inputs can be usedAtStart.
Sorry about this bug, regalloc is hard :/

Comment 11

[Benjamin Bouvier [:bbouvier] (inactive)]

Filed bug 1068725 to make sure this doesn't happen again in the future.

Comment 12

[Benjamin Bouvier [:bbouvier] (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4a1a4d119980

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4a1a4d119980

Comment 14

[James Kitchener (:jkitch)]

This is still crashing for me, in both Nightly and self-compiled debug Win32 builds.

https://crash-stats.mozilla.com/report/index/f9947945-2c07-43c0-98d4-9aeaf2140930

If I backout 4a1a4d119980 and apply the patch in attachment 8490734 [details] [diff] [review], the crash goes away.

I've included what I presume is the assembly generated by the javascript compiler in case it proves to be helpful.

0BEA0030  inc         esp  
0BEA0031  and         al,40h  
0BEA0033  movaps      xmm0,xmmword ptr ds:[0BEA17F0h]  
0BEA003A  movaps      xmmword ptr [esp+10h],xmm0  
0BEA003F  pxor        xmm4,xmm4  
0BEA0043  movdqa      xmm0,xmmword ptr ds:[0BEA1800h]  
0BEA004B  movdqa      xmmword ptr [esp],xmm0  
0BEA0050  movaps      xmm0,xmmword ptr [esp+70h]  
0BEA0055  shufps      xmm0,xmm0,0  
0BEA0059  movss       xmm2,dword ptr [esp+80h]  
0BEA0062  movaps      xmmword ptr [esp+50h],xmm0  
0BEA0067  addss       xmm2,dword ptr [esp+78h]  
0BEA006D  movss       xmm3,dword ptr [esp+80h]  
0BEA0076  addss       xmm3,xmm2  
0BEA007A  movss       xmm0,dword ptr [esp+80h]  
0BEA0083  addss       xmm0,xmm3  
0BEA0087  movaps      xmm5,xmm2  
0BEA008A  movaps      xmm1,xmmword ptr [esp+78h]  ;Crash occurs here
0BEA008F  unpcklps    xmm5,xmm0  
0BEA0092  unpcklps    xmm1,xmm3  
0BEA0095  unpcklps    xmm1,xmm5  
0BEA0098  xor         eax,eax  
0BEA009A  movdqa      xmm0,xmm4  
0BEA009E  movaps      xmm6,xmm1  
0BEA00A1  movaps      xmm4,xmmword ptr [esp+50h]  
0BEA00A6  cmp         eax,64h  
0BEA00A9  jge         0BEA0106
...

Crash reason: Unhandled exception at 0x0BEA008A in firefox.exe: 0xC0000005: Access violation reading location 0x00000000.

Register values
ESP     1E49D910	
XMM0	000000000000000000000000BF7C28F6	
XMM1	0000000000000000000000003CA3D70A	
XMM2	000000000000000000000000BF7EB852	
XMM3	000000000000000000000000BF7D70A4	
XMM5	000000000000000000000000BF7EB852	

I've also tried applying the patch from bug 1072083, but that didn't help.

Let me know if there is any additional information that you need to diagnose the crash.

Comment 15

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks for the report! I think this issue is tracked in bug 1068725. Is it solved if you apply patch 2) of that bug?

Comment 16

[James Kitchener (:jkitch)]

Yes, that fixes the issue

Comment 17

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks, feel free to keep an eye on bug 1068725 then to track this new issue.

Comment 18

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Reproduced the original tab crash with Firefox 35 Nightly from September 16th (BuildID=20140916030204) on Windows 7 x64, just as described in comment 0. The crash no longer occurs in the latest Firefox 37 Nightly (BuildID=20141214030205).

Comment 19

[wael72Daoud]

Memory leak/dangling:
- Firefox (Developer Edition 49.0a2 (2016-07-15))
- OS: Windows 10 Home(version 1511 build 10586.494) - EN
- CPU: Intel Core due I5
- Memory: 8 GB


PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffffd001a6607190, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff800f6729060, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 0000000000000001, (reserved)

Debugging Details:
------------------


Could not read faulting driver name

READ_ADDRESS:  ffffd001a6607190 

FAULTING_IP: 
NTFS!memcpy+2e0
fffff800`f6729060 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h]

MM_INTERNAL_CODE:  1

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR:  AV

PROCESS_NAME:  firefox.exe

CURRENT_IRQL:  2

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

TRAP_FRAME:  ffffd00021be3e20 -- (.trap 0xffffd00021be3e20)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=ffffe00132bce1a0
rdx=fffff00073a39000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800f6729060 rsp=ffffd00021be3fb8 rbp=fffff800f5ff7895
 r8=00000000000801a0  r9=000000000000400d r10=0000000000040000
r11=ffffe00132b4e000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
NTFS!memcpy+0x2e0:
fffff800`f6729060 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h] ds:ffffd001`a6607190=????????????????????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800cce00c93 to fffff800ccdbb940

STACK_TEXT:  
ffffd000`21be3bc8 fffff800`cce00c93 : 00000000`00000050 ffffd001`a6607190 00000000`00000000 ffffd000`21be3e20 : nt!KeBugCheckEx
ffffd000`21be3bd0 fffff800`ccd16621 : 00000000`00000000 ffffc001`58fcc9d0 ffffd000`21be3e20 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x36993
ffffd000`21be3cc0 fffff800`ccdc4bbc : 00000000`00000000 fffff800`ccf8cb80 ffffe001`32b4e000 00000000`00000801 : nt!MmAccessFault+0x5f1
ffffd000`21be3e20 fffff800`f6729060 : fffff800`f679bcfe ffffc001`58fcc9d0 00000000`00081000 ffffc001`58fcc9d0 : nt!KiPageFault+0x13c
ffffd000`21be3fb8 fffff800`f679bcfe : ffffc001`58fcc9d0 00000000`00081000 ffffc001`58fcc9d0 ffffc001`58fcc890 : NTFS!memcpy+0x2e0
ffffd000`21be3fc0 fffff800`f679b63d : ffffe001`23eeadc8 ffffe001`32b4e000 00000000`00000080 ffffd000`21be4128 : NTFS!NtfsCreateNonresidentWithValue+0x232
ffffd000`21be40b0 fffff800`f67b668b : ffffb001`f17af190 fffff800`f5ff7895 ffffc001`58fcc9d0 00000000`00000000 : NTFS!NtfsConvertToNonresident+0x2e1
ffffd000`21be4260 fffff800`f67a8fcf : ffffc001`58fcc9d0 fffff800`f5ff7895 ffffe001`23eeadc8 00000000`00008000 : NTFS!NtfsChangeAttributeValue+0xb37
ffffd000`21be4460 fffff800`f67a7995 : ffffc001`58fcc901 ffffc001`58fcc9d0 ffffc001`00000000 00000000`00000000 : NTFS!NtfsSetEndOfFileInfo+0x4d3
ffffd000`21be4590 fffff800`f67a748d : ffffe001`23eeadc8 ffffe001`25152630 ffffe001`25152600 ffffc001`58fccbc0 : NTFS!NtfsCommonSetInformation+0x415
ffffd000`21be4670 fffff800`cd32acbc : ffffe001`269d3b90 ffffe001`25152630 ffffe001`23eeadc8 ffffd000`21be46b0 : NTFS!NtfsFsdSetInformation+0xdd
ffffd000`21be4710 fffff800`ccd44cd2 : ffffe001`2ba92010 00000000`00000000 ffffe001`25152630 00000000`00000000 : nt!IovCallDriver+0x50
ffffd000`21be4750 fffff800`f5ff7895 : ffffd000`21be4840 00000000`00000000 ffffe001`25152a06 ffffe001`2bc82d00 : nt!IofCallDriver+0x72
ffffd000`21be4790 fffff800`f5ff5816 : ffffe001`2bc82d10 00000000`00000000 00000000`00000001 00000000`00000000 : FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x1a5
ffffd000`21be4820 fffff800`cd32acbc : ffffe001`25152630 fffff800`ccd398bd ffffe001`00000000 00000000`00000008 : FLTMGR!FltpDispatch+0xb6
ffffd000`21be4880 fffff800`cccfde50 : ffffe001`25152630 ffffe001`269bad10 00000000`00000001 00000000`00000002 : nt!IovCallDriver+0x50
ffffd000`21be48c0 fffff800`cccfdd0e : ffffe001`2c3fa7a8 ffffd000`21be4b80 00000000`00000000 00000000`00000000 : nt!IoCallDriverWithTracing+0x60
ffffd000`21be4920 fffff800`cccea34f : ffffd000`21be4b80 ffffe001`25152630 ffffe001`25152630 00000000`00000008 : nt!IopCallDriverReference+0x8e
ffffd000`21be4950 fffff800`ccdc61a3 : 00000000`00000680 00000000`0cbee438 00000000`0cbee3b0 00000000`00000008 : nt!NtSetInformationFile+0xacf
ffffd000`21be4a90 00007ffa`56ad55c4 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0cbee378 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffa`56ad55c4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
NTFS!memcpy+2e0
fffff800`f6729060 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  NTFS!memcpy+2e0

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: NTFS

IMAGE_NAME:  NTFS.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  56fa1d8d

IMAGE_VERSION:  10.0.10586.212

BUCKET_ID_FUNC_OFFSET:  2e0

FAILURE_BUCKET_ID:  AV_VRF_NTFS!memcpy

BUCKET_ID:  AV_VRF_NTFS!memcpy

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:av_vrf_ntfs!memcpy

FAILURE_ID_HASH:  {42897693-3f38-2825-9348-02f570d06af5}

Followup: MachineOwner
---------

3: kd> .trap 0xffffd00021be3e20
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=ffffe00132bce1a0
rdx=fffff00073a39000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800f6729060 rsp=ffffd00021be3fb8 rbp=fffff800f5ff7895
 r8=00000000000801a0  r9=000000000000400d r10=0000000000040000
r11=ffffe00132b4e000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
NTFS!memcpy+0x2e0:
fffff800`f6729060 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h] ds:ffffd001`a6607190=????????????????????????????????

Comment 20

[Benjamin Bouvier [:bbouvier] (inactive)]

(In reply to wael72Daoud from comment #19)
Hi, can you give us some context here? What is this? Under which platform/architecture do you reproduce this bug? Which version of Firefox? What makes you believe it is something caused by this bug? (hint, it can't be, because you're running Firefox Developer Edition, on which SIMD is disabled) As it looks unrelated, can you open a new bug instead, and make an explicit list of steps needed to reproduce the issue you're seeing, please?

Comment 21

[Benjamin Bouvier [:bbouvier] (inactive)]

No answer in three months, cancelling needinfo. If you see something strange, please open a new bug.