This bug was filed from the Socorro interface and is report bp-7d2ec945-4bc2-4a2b-8505-0a9082121217 . ============================================================= Steps: 1. Load http://etherpad.mozilla.org/app-install-testing in the nightly browser Expected: The etherpad should load without crashing. Actual: Firefox crashes. 0 mozjs.dll js::ion::CodeGeneratorShared::encode js/src/ion/shared/CodeGenerator-shared.cpp:216 1 mozjs.dll js::ion::CodeGenerator::visitOsiPoint js/src/ion/CodeGenerator.cpp:335 2 mozjs.dll js::ion::LOsiPoint::accept js/src/ion/LIR-Common.h:72 3 mozjs.dll js::ion::CodeGenerator::generateBody js/src/ion/CodeGenerator.cpp:1505 4 mozjs.dll js::ion::CodeGenerator::generate js/src/ion/CodeGenerator.cpp:3158 5 mozjs.dll js::ion::CompileBackEnd js/src/ion/Ion.cpp:1038 6 mozjs.dll js::WorkerThread::threadLoop js/src/jsworkers.cpp:325 7 mozjs.dll js::WorkerThread::ThreadMain js/src/jsworkers.cpp:293 8 nspr4.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:395 9 nspr4.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:90 10 msvcr100.dll _callthreadstartex f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314 11 msvcr100.dll _threadstartex f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292 12 kernel32.dll kernel32.dll@0x133a9 13 ntdll.dll __RtlUserThreadStart 14 ntdll.dll _RtlUserThreadStart

It doesn't crash for me with a new profile. I started spiking in 20.0a1/20121216. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ea1c76e4bb3&tochange=c8a1314aa449 More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3ACodeGeneratorShared%3A%3Aencode%28js%3A%3Aion%3A%3ALSnapshot*%29

Still able to crash with the etherpad referenced on nightly on win 7 64-bit

It's #4 top crasher in today's build.

I can reproduce now.

Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/bb2f453b7c0f Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121214 Firefox/20.0 ID:20121215061721 Bad: http://hg.mozilla.org/mozilla-central/rev/c8a1314aa449 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121216 Firefox/20.0 ID:20121216030851 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bb2f453b7c0f&tochange=c8a1314aa449 Regression window(m-c) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/061b5c0c5580 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121214 Firefox/20.0 ID:20121214120919 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/b7e2ba73b2ff Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121214 Firefox/20.0 ID:20121214122320 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=061b5c0c5580&tochange=b7e2ba73b2ff Suspected: Bug 808245

Sean, you landed bug 808245, which caused this, can you please take a look at what's going on there?

https://crash-stats.mozilla.com/report/index/bp-618279bf-d6f2-4a3b-ba14-7a8702121219 https://crash-stats.mozilla.com/report/index/bp-07a2bb84-cd59-4b50-a702-54d352121219 Getting back to back crashes.

This blocks work for a Mozilla contributors who use nightly. Is this getting backed out or fixed soon?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6) > Sean, you landed bug 808245, which caused this, can you please take a look > at what's going on there? Looking into it.

(In reply to Kevin Brosnan [:kbrosnan] from comment #8) > This blocks work for a Mozilla contributors who use nightly. Is this getting > backed out or fixed soon? I can only reproduce crashes (with a different signature) with parallel compilation enabled. If you would like to work with the current Nightly before I diagnose the cause or back out the changesets, you could try setting javascript.options.ion.parallel_compilation to false as a temporary stopgap.

We have a fix; for diagnosis, see Bug 823152. Brian should commit it shortly.

This should fix the crash (wrong allocator used for certain compiler objects which could manifest in a crash when they were accessed off thread). r+ from sstangl over IRC. https://hg.mozilla.org/integration/mozilla-inbound/rev/cc2edd53d5e9

Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130220104816 Firefox 20 beta 1 does not crash when loading the etherpad from the Description or when following the scenario from the duplicate bug, but I get a different signature when reproducing the initial crash. https://crash-stats.mozilla.com/report/index/bp-bf18ed9e-5f0b-47d2-b792-63f5d2130222 Is this expected in any way?

(In reply to Simona B [QA] from comment #16) > https://crash-stats.mozilla.com/report/index/bp-bf18ed9e-5f0b-47d2-b792- > 63f5d2130222 The build is too old to have debug symbols.

Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130220104816 Verified that Firefox 20 beta 1 does not crash on Ubuntu 12.10 and Mac OS X 10.8 when following the STR from the Description and from the duplicate Bug. Also there are no crash reports in Socorro on Firefox 20 beta 1 for the signature related with this bug. Based on this and on Comments 16 and 17 - setting the tracking flag for Firefox 20 to verified.