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

VERIFIED FIXED

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
8 years ago
3 years ago

People

(Reporter: marcia, Assigned: dvander)

Tracking

({crash})

Trunk
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical][ccbr] fixed-in-tracemonkey [critsmash:resolved], crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
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.
Summary: Crash in Firefox 3.7a5pre Crash Report [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ] → Crash [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ]
(Reporter)

Comment 2

8 years ago
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
OS: Windows 7 → All
Hardware: x86 → All
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)
(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?
(Assignee)

Comment 5

8 years ago
Reproduced on m-c, so this is not bug 558633. Investigating...
(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.
(Assignee)

Comment 7

8 years ago
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.
Group: core-security
(Assignee)

Comment 8

8 years ago
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?
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.
(Assignee)

Comment 10

8 years ago
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.
(Assignee)

Comment 11

8 years ago
Created attachment 442003 [details] [diff] [review]
fix

so it seems like the fix is to just not overwrite v_ins then
Attachment #442003 - Flags: review?(vladimir)
(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 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.
Attachment #442003 - Flags: review?(vladimir) → review+
(Assignee)

Comment 14

8 years ago
Created attachment 442009 [details]
test case

test case omitted from checkin for security

http://hg.mozilla.org/tracemonkey/rev/dd7d9ebc127c
(Assignee)

Updated

8 years ago
Whiteboard: [sg:critical][ccbr] fixed-in-tracemonkey
(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?

Updated

8 years ago
Assignee: general → dvander

Comment 16

8 years ago
http://hg.mozilla.org/mozilla-central/rev/dd7d9ebc127c
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

8 years ago
Whiteboard: [sg:critical][ccbr] fixed-in-tracemonkey → [sg:critical][ccbr] fixed-in-tracemonkey [critsmash:patch]
(Reporter)

Comment 17

8 years ago
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.
Status: RESOLVED → VERIFIED

Updated

8 years ago
Whiteboard: [sg:critical][ccbr] fixed-in-tracemonkey [critsmash:patch] → [sg:critical][ccbr] fixed-in-tracemonkey [critsmash:resolved]
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.
Summary: Crash [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ] → Typed arrays crash [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ]
Crash Signature: [@ js::MonitorLoopEdge(JSContext*, unsigned int&, js::RecordReason) ]
Group: core-security
You need to log in before you can comment on or make changes to this bug.