Nightly 22.0a1 (2013-03-24) crashes on running asm.js code in a worker

RESOLVED FIXED in mozilla22



JavaScript Engine
5 years ago
5 years ago


(Reporter: Andre Weissflog, Assigned: sstangl)


({crash, regression, reproducible})

22 Branch
crash, regression, reproducible

Firefox Tracking Flags

(Not tracked)


(crash signature)


(3 attachments)



5 years ago
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:

Notice how the browser crashes when running the code, then try the non-asm.js version which works:

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.

Comment 1

5 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.

Comment 2

5 years ago
Correction to previous comment: setting the flag to "false" of course.

Comment 3

5 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

5 years ago
Here's a crash report:
running the ammo.js falling blocks demo:
Severity: normal → critical
Crash Signature: [@ pthread_mutex_lock | PR_Lock | js::CancelOffThreadIonCompile(JSCompartment*, JSScript*) ]
Ever confirmed: true
Keywords: crash

Comment 5

5 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

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

5 years ago
I verified the Nebula 3 dragons demo also uses workers, further supporting the workers theory.


5 years ago
Assignee: general → sstangl

Comment 7

5 years ago
Created attachment 728759 [details] [diff] [review]
Only initialize WorkerThreadState if parallel mode is enabled.

I hoisted this check to fix a nit but forgot to propagate the conditions surrounding its execution.
Attachment #728759 - Flags: review?(luke)


5 years ago
Keywords: reproducible

Comment 8

5 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+

Comment 9

5 years ago


5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED


5 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
Created attachment 729049 [details]
asm worker test

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.
Created attachment 729050 [details]
asm worker test worker

Worker script for test.

Comment 13

5 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.