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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Andre Weissflog]

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.

Comment 1

[Andre Weissflog]

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

[Andre Weissflog]

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

Comment 3

[Luke Wagner [:luke]]

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

[Luke Wagner [:luke]]

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

Comment 5

[Alon Zakai (:azakai)]

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

Comment 6

[Alon Zakai (:azakai)]

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

Comment 7

[Sean Stangl [:sstangl]]

Attachment: 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.

Comment 8

[Luke Wagner [:luke]]

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?

Comment 9

[Sean Stangl [:sstangl]]

https://hg.mozilla.org/mozilla-central/rev/3acbf951b3b1
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f9a36fafdfd

Comment 10

[Joe Drew (not getting mail)]

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

Comment 11

[Alon Zakai (:azakai)]

Attachment: 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.

Comment 12

[Alon Zakai (:azakai)]

Attachment: asm worker test worker

Worker script for test.

Comment 13

[Luke Wagner [:luke]]

I agreed we need to mochitest all these things; bug 854209 is high on the post-GDC priority list.