561813 - Typed arrays crash [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Marcia Knous [:marcia]]

Seen while running  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100426 Minefield/3.7a5pre

STR:
1. Load the site in the URL and pick a generation.
2. I used the default generator with compositing checked.
3. Crash

https://crash-stats.mozilla.com/report/index/277c0674-ce4f-49ed-b2f9-134202100424 is my report.

Comment 1

[Marcia Knous [:marcia]]

The crash does not happen right away, so you might have wait a minute or so before it happens. Haven't yet been able to reproduce on Mac because it cannot connect to the site.

Comment 2

[Marcia Knous [:marcia]]

http://tinyurl.com/2b6ndpg links to the current reports in crash-stats. I was able to reproduce the crash on Mac so I updated the summary accordingly. https://crash-stats.mozilla.com/report/index/bp-4b36b4b6-c604-4c72-b497-f95122100426 is the Mac crash.


Frame  	Module  	Signature [Expand]  	Source
0 		@0x36deda5 	
1 	mozjs.dll 	js::MonitorLoopEdge 	js/src/jstracer.cpp:7012
2 	mozjs.dll 	js_Interpret 	js/src/jsops.cpp:919
3 	mozjs.dll 	js_Invoke 	js/src/jsinterp.cpp:842
4 	mozjs.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:899
5 	mozjs.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:4947
6 	xul.dll 	nsJSContext::CallEventHandler 	dom/base/nsJSEnvironment.cpp:2163
7 	xul.dll 	nsGlobalWindow::RunTimeout 	dom/base/nsGlobalWindow.cpp:8499
8 	xul.dll 	nsGlobalWindow::TimerCallback 	dom/base/nsGlobalWindow.cpp:8843
9 	xul.dll 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:427
10 	nspr4.dll 	_PR_MD_UNLOCK 	nsprpub/pr/src/md/windows/w95cv.c:344
11 	xul.dll 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:519
12 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:527
13 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:142
14 	xul.dll 	xul.dll@0x96efbb 	
15 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:216
16 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:199
17 	xul.dll 	xul.dll@0x2e5e13 	
18 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:173
19 	nspr4.dll 	nspr4.dll@0x187ff 	
20 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:174
21 	xul.dll 	nsAppShell::Run 	widget/src/windows/nsAppShell.cpp:239
22 		@0x77bcffff 	
23 		@0x759fffff 	
24 	xul.dll 	nsPrintEngine::SetupToPrintContent 	layout/printing/nsPrintEngine.cpp:1753
25 		@0x764affff

Comment 3

[Mats Palmgren (inactive)]

mozilla-central debug build on OSX (32-bit):
Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'gtd' is 'calli' which has type int32 (expected float64): 0 (js/src/nanojit/LIR.cpp:2635)

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to comment #3)
> mozilla-central debug build on OSX (32-bit):
> Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'gtd' is
> 'calli' which has type int32 (expected float64): 0
> (js/src/nanojit/LIR.cpp:2635)

Will this have been recently (really recently) been fixed by the latest LIR type error fix for bug 558633?

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

Reproduced on m-c, so this is not bug 558633. Investigating...

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to comment #4)
> (In reply to comment #3)
> > mozilla-central debug build on OSX (32-bit):
> > Assertion failed: LIR type error (start of writer pipeline): arg 1 of 'gtd' is
> > 'calli' which has type int32 (expected float64): 0
> > (js/src/nanojit/LIR.cpp:2635)
> 
> Will this have been recently (really recently) been fixed by the latest LIR
> type error fix for bug 558633?

I doubt it -- bug 558633 was an int32 vs. int64 type error, this is an int32 vs. float64 type error.

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

This looks like a bug in typed arrays, Yet Another Case of the expected types in the tracer not matching the types in the interpreter. Going to try and get a test case.

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

function f() {
    var x = new Int8Array([1, 2, 3, 4, 5]);
    var c = (x[4] = "9872");
    x[4] = "9872";
    var d = x[4];
    print(c);
    print(d);
}
f();

This prints "9872", "-112" - my guess is it's supposed to print "-112" both times. Vlad, can you confirm the intended semantics?

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

for some reason I thought that x = (a = b), x is supposed to be == b, not the value that's assigned to a.  If the latter, then yeah, it needs to get fixed.

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

Hrm you might be right, from jsops.cpp:

   if (!obj->setProperty(cx, id, &rval))
        goto error;
  end_setelem:
END_SET_CASE_STORE_RVAL(JSOP_SETELEM, 3)

#define END_SET_CASE_STORE_RVAL(OP,spdec)                                     \
            SKIP_POP_AFTER_SET(OP##_LENGTH, spdec);                           \
            rval = FETCH_OPND(-1);                  

If the object overrides the rval, the interpreter won't pick it up. So this might just be a tracer bug.

Comment 11

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

so it seems like the fix is to just not overwrite v_ins then

Comment 12

[Jeff Walden [:Waldo]]

(In reply to comment #10)
> If the object overrides the rval, the interpreter won't pick it up. So this
> might just be a tracer bug.

Won't pick it up, and shouldn't pick it up -- (a = b) always evaluates to b.  We used to implement the other way (prior to Firefox 3?) but changed because ECMA required otherwise.

Shouldn't the test assert that c and d are "9872" and -112 respectively?

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 442003 [details] [diff] [review]
fix

yeah, bug in the tracing code -- and yes, the test should really assert "9872" and -112 instead of just checking that it doesn't crash.

Comment 14

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: test case

test case omitted from checkin for security

http://hg.mozilla.org/tracemonkey/rev/dd7d9ebc127c

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #14)
> Created an attachment (id=442009) [details]
> test case
> 
> test case omitted from checkin for security

Why?  This isn't in a shipping build, no?

Comment 16

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/dd7d9ebc127c

Comment 17

[Marcia Knous [:marcia]]

Verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a5pre) Gecko/20100507 Minefield/3.7a5pre as well as the Windows equivalent build. I verified using the web site in the URL field.

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Note: this crash signature is generic, and as such if you're here from the crash reporter, this bug here is specifically about WebGL & typed arrays.