With the stack trace below, it first showed up in 23.0a1/20130502. A comment talks about Epic Citadel (http://www.unrealengine.com/html5/) and Inspector opened. Signature js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&) More Reports Search UUID 1a5c4351-0c2a-41e7-8bf2-8f4392130503 Date Processed 2013-05-03 07:15:53 Uptime 163 Last Crash 18.8 minutes before submission Install Age 3.8 minutes since version was first installed. Install Time 2013-05-03 07:11:57 Product Firefox Version 23.0a1 Build ID 20130502030939 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 42 stepping 7 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0xe App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x0102, AdapterSubsysID: 365317aa, AdapterDriverVersion: 184.108.40.20667 D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ Processor Notes sp-processor09.phx1.mozilla.com_11692:2012 EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x0102 Total Virtual Memory 4294836224 Available Virtual Memory 2866905088 System Memory Use Percentage 66 Available Page File 4024258560 Available Physical Memory 1420836864 Accessibility Active Frame Module Signature Source 0 mozjs.dll js::types::TypeMonitorResult js/src/jsinfer.cpp:5854 1 mozjs.dll js::Interpret js/src/jsinterp.cpp:2312 2 mozjs.dll js::RunScript js/src/jsinterp.cpp:377 3 mozjs.dll js::InvokeKernel js/src/jsinterp.cpp:442 4 mozjs.dll js::Invoke js/src/jsinterp.cpp:475 5 mozjs.dll js::ion::DoCallFallback js/src/ion/BaselineIC.cpp:6587 6 @0x35cde4 7 @0x35cd9c 8 @0xffffff87 More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeMonitorResult%28JSContext*%2C+JSScript*%2C+unsigned+char*%2C+JS%3A%3AValue+const%26%29
Forgot to mention: By demo, I mean Epic Citadel
I can reproduce also with the STR of comment 1 (crash during loading). It's currently #3 top crasher in today's build.
tracking-firefox23: --- → ?
Keywords: reproducible, topcrash
I can no longer reproduce it in the build from May 5 and I don't see it in crash stats.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
tracking-firefox23: ? → ---
Resolution: --- → WORKSFORME
There are still a few crashes in crash stats.
Status: RESOLVED → REOPENED
Keywords: reproducible, topcrash
Resolution: WORKSFORME → ---
And it has been again reproducible and a top crash (25 crashes per build) since 23.0a1/20130506. In Aurora, I get bp-64a239fe-7ce5-42ab-9207-0fbce2130507.
status-firefox21: --- → unaffected
status-firefox22: --- → affected
tracking-firefox23: --- → ?
Keywords: regression, topcrash
Version: Trunk → 22 Branch
Luke - can you take a look? We're not sure if this is worth tracking since it'll be a very low volume crasher on Beta/Release, but do think it's worth an investigation given volume on Nightly.
Assignee: general → luke
tracking-firefox22: --- → ?
All the crashes are at http://hg.mozilla.org/mozilla-central/annotate/b842d26dd5f0/js/src/jsinfer.cpp#l5813 at address 0xe and on x86 so this looks to be another OOM crash, like bug 868334. The fact that turning off Odin produces a somewhat reproducible OOM crash (comment 1) and the crash address suggest we're simply missing an OOM check somewhere in ensureRanAnalysis. As with bug 868334, we're just seeing a spike because the demo runs a huge amount of code. Perhaps bhackett could take a look?
The chain of logic around TypeMonitorResult was just overhauled for bug 865059 (ensureRanAnalysis isn't called anymore, in particular). It would be good to know how that affects this signature.
No crashes starting with the May 8th nightly (20130508031113) which is the first nightly to contain bug 865059, so looks promising.
(In reply to Brian Hackett (:bhackett) from comment #9) > The chain of logic around TypeMonitorResult was just overhauled for bug > 865059 (ensureRanAnalysis isn't called anymore, in particular). It would be > good to know how that affects this signature. Probably too risky to land on beta for FF22 though right?
(In reply to Alex Keybl [:akeybl] from comment #11) > (In reply to Brian Hackett (:bhackett) from comment #9) > > The chain of logic around TypeMonitorResult was just overhauled for bug > > 865059 (ensureRanAnalysis isn't called anymore, in particular). It would be > > good to know how that affects this signature. > > Probably too risky to land on beta for FF22 though right? Yeah, I think so. How much does this crash affect 22?
(In reply to Brian Hackett (:bhackett) from comment #12) > Yeah, I think so. How much does this crash affect 22? In 22.0, it's bug 799118 which is #66 browser crasher in that version.
status-firefox22: affected → wontfix
tracking-firefox22: ? → -
tracking-firefox23: ? → +
This bug and bug 866397 are #80 browser crasher in 23.0a2 and #197 in 24.0a1 so it's almost fully fixed by one of the patch in bug 865059.
status-firefox23: affected → fixed
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 Verified as fixed on Firefox 23 Beta 1 (buildID: 20130625125232) and latest Nightly (buildID: 20130625031238).
status-firefox23: fixed → verified
This was verified on Windows 7 x32. Ignore the User Agents from comment 15.
Scoobidiver, is it safe to mark this bug's status to VERIFIED FIXED now?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #17) > Scoobidiver, is it safe to mark this bug's status to VERIFIED FIXED now? I can't reproduce the crash in 23.0b2 after loading the Epic Citadel demo. There's still bug 866397 to track crashes with this signature.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.