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.
Correction to previous comment: setting the flag to "false" of course.
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
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.)
I verified the Nebula 3 dragons demo also uses workers, further supporting the workers theory.
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.
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?
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.
I agreed we need to mochitest all these things; bug 854209 is high on the post-GDC priority list.