Closed
Bug 854197
Opened 11 years ago
Closed 11 years ago
Nightly 22.0a1 (2013-03-24) crashes on running asm.js code in a worker
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla22
People
(Reporter: floooh, Assigned: sstangl)
References
Details
(Keywords: crash, regression, reproducible)
Crash Data
Attachments
(3 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20130324 Firefox/22.0 Build ID: 20130324031024 Steps to reproduce: With Nightly 22.0a1 (2013-03-24) on OSX 10.7.5 (not tested on other configs), navigate here: http://n3emscripten.appspot.com/dragons_asmjs.html Notice how the browser crashes when running the code, then try the non-asm.js version which works: http://n3emscripten.appspot.com/dragons.html This seems to be a regression, the code worked in the OdinMonkey branch. Actual results: Crash with crash report dialog box. Expected results: The asm.js versions of the demos should not crash the browser.
Reporter | ||
Comment 1•11 years ago
|
||
PS: setting javascript.options.experimental_asmjs in about:config makes the code run, so it really seems to be something in the asm.js subsystem.
Reporter | ||
Comment 2•11 years ago
|
||
Correction to previous comment: setting the flag to "false" of course.
Comment 3•11 years ago
|
||
Sean, this reproduces for me w/ and w/o javascript.options.ion.parallel_compilation enabled. Under a debugger, the fault stack is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 [Switching to process 11693 thread 0xd903] 0x00007fff903dbb99 in pthread_mutex_lock () (gdb) bt #0 0x00007fff903dbb99 in pthread_mutex_lock () #1 0x0000000101110a3e in PR_Lock () #2 0x0000000103067611 in js::CancelOffThreadIonCompile () #3 0x00000001031d47e0 in js::ion::ForbidCompilation () #4 0x00000001031d5186 in js::ion::CanEnter () #5 0x0000000102fc859a in js::RunScript () #6 0x0000000102fd31ce in js::ExecuteKernel () #7 0x0000000102fd3310 in js::Execute () #8 0x0000000102f5e3f8 in JS::Evaluate () #9 0x0000000101cac917 in (anonymous namespace)::ScriptExecutorRunnable::WorkerRun () #10 0x0000000101caee30 in mozilla::dom::workers::WorkerRunnable::Run () #11 0x0000000101cb2652 in mozilla::dom::workers::WorkerPrivate::RunSyncLoop () #12 0x0000000101cab35a in (anonymous namespace)::LoadAllScripts () #13 0x0000000101cab256 in mozilla::dom::workers::scriptloader::LoadWorkerScript () #14 0x0000000101cb5d55 in (anonymous namespace)::CompileScriptRunnable::WorkerRun () #15 0x0000000101caee30 in mozilla::dom::workers::WorkerRunnable::Run () #16 0x0000000101cb06a0 in mozilla::dom::workers::WorkerPrivate::DoRunLoop () #17 0x0000000101ca9ecc in (anonymous namespace)::WorkerThreadRunnable::Run () #18 0x00000001027eba6d in nsThread::ProcessNextEvent () #19 0x00000001027a4370 in NS_ProcessNextEvent_P () #20 0x00000001027eaded in nsThread::ThreadFunc () #21 0x000000010111320b in _pt_root () #22 0x00007fff903d6742 in _pthread_start () #23 0x00007fff903c3181 in thread_start () Looks like we're in a web worker trying to run IonMonkey code.
Comment 4•11 years ago
|
||
Here's a crash report: https://crash-stats.mozilla.com/report/index/bp-1b41fb37-ce16-49b1-ad6b-06c1b2130324 running the ammo.js falling blocks demo: http://kripken.github.com/ammo.js/examples/new/ammo.html
Updated•11 years ago
|
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ pthread_mutex_lock | PR_Lock | js::CancelOffThreadIonCompile(JSCompartment*, JSScript*) ]
Ever confirmed: true
Keywords: crash
Comment 5•11 years ago
|
||
This is 100% reproducible with the ammo demo, and only when it has 'use asm'. The ammo demo uses a worker. No problems with asm.js demos on the main thread, e.g. BananaBread is fine https://developer.mozilla.org/demos/detail/bananabread And the crash is in threading code. So I am guessing this is due to parallel asm.js compilation which just landed, seems to be a problem when it happens in a worker. Can we perhaps disable parallel compilation on workers for now? (It's much less needed there anyhow.)
Blocks: 850070
OS: Mac OS X → All
Hardware: x86 → All
Summary: Nightly 22.0a1 (2013-03-24) on OSX crashes on running asm.js code → Nightly 22.0a1 (2013-03-24) crashes on running asm.js code in a worker
Comment 6•11 years ago
|
||
I verified the Nebula 3 dragons demo also uses workers, further supporting the workers theory.
Assignee | ||
Updated•11 years ago
|
Assignee: general → sstangl
Assignee | ||
Comment 7•11 years ago
|
||
I hoisted this check to fix a nit but forgot to propagate the conditions surrounding its execution.
Attachment #728759 -
Flags: review?(luke)
Keywords: reproducible
Comment 8•11 years ago
|
||
Comment on attachment 728759 [details] [diff] [review] Only initialize WorkerThreadState if parallel mode is enabled. Can you land directly on m-c to ensure this gets into tonight's nightly?
Attachment #728759 -
Flags: review?(luke) → review+
Assignee | ||
Comment 9•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3acbf951b3b1 https://hg.mozilla.org/integration/mozilla-inbound/rev/4f9a36fafdfd
Assignee | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Crash Signature: [@ pthread_mutex_lock | PR_Lock | js::CancelOffThreadIonCompile(JSCompartment*, JSScript*) ] → [@ pthread_mutex_lock | PR_Lock | js::CancelOffThreadIonCompile(JSCompartment*, JSScript*) ]
[@ RtlEnterCriticalSection | PR_Lock | js::CancelOffThreadIonCompile(JSCompartment*, JSScript*) ]
[@ libsystem_c.dylib@0x19bf9 ]
Keywords: regression
Target Milestone: --- → mozilla22
Comment 11•11 years ago
|
||
I think we should add a test for OdinMonkey compilation in workers, to make sure this does not regress again. Attached is a test that I verified crashes 100% consistently with the previous nightly where this was a problem.
Comment 12•11 years ago
|
||
Worker script for test.
Comment 13•11 years ago
|
||
I agreed we need to mochitest all these things; bug 854209 is high on the post-GDC priority list.
You need to log in
before you can comment on or make changes to this bug.
Description
•