It's #24 top crasher in 9.0b1. It might be related to bug 698296. It first appeared in 9.0a1/20110904. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=472716252ea3&tochange=a351ae35f2c4 It's likely a regression from bug 681884. Signature js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) UUID 5f4db57b-be69-4557-8907-8ebbc2111112 Date Processed 2011-11-12 23:44:18.370545 Uptime 45466 Last Crash 13.1 hours before submission Install Age 1.0 days since version was first installed. Install Time 2011-11-12 06:51:20 Product Firefox Version 9.0 Build ID 20111109112850 Release Channel beta OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info AuthenticAMD family 16 model 6 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION_EXEC Crash Address 0x5ffffff User Comments App Notes AdapterVendorID: 1002, AdapterDeviceID: 9712, AdapterSubsysID: 1b621043, AdapterDriverVersion: 8.722.0.0 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- Frame Module Signature [Expand] Source 0 @0x5ffffff 1 mozjs.dll js::gc::Arena::finalize<JSObject> js/src/jsgc.cpp:301 2 mozjs.dll js::gc::FinalizeTypedArenas<JSObject> js/src/jsgc.cpp:348 3 mozjs.dll js::gc::ArenaLists::finalizeObjects js/src/jsgc.cpp:1387 4 mozjs.dll SweepPhase js/src/jsgc.cpp:2316 5 mozjs.dll MarkAndSweep js/src/jsgc.cpp:2402 6 mozjs.dll GCCycle js/src/jsgc.cpp:2645 7 mozjs.dll js_GC js/src/jsgc.cpp:2731 8 mozjs.dll JS_CompartmentGC js/src/jsapi.cpp:2616 9 mozjs.dll JS_GC js/src/jsapi.cpp:2623 10 xul.dll nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:414 11 xul.dll nsCycleCollector::GCIfNeeded xpcom/base/nsCycleCollector.cpp:2615 12 xul.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:2696 13 xul.dll nsCycleCollector::Shutdown xpcom/base/nsCycleCollector.cpp:2915 14 xul.dll nsCycleCollector_shutdown xpcom/base/nsCycleCollector.cpp:3630 15 xul.dll mozilla::ShutdownXPCOM xpcom/build/nsXPComInit.cpp:659 16 xul.dll ScopedXPCOMStartup::~ScopedXPCOMStartup toolkit/xre/nsAppRunner.cpp:1084 17 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3587 18 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:107 19 firefox.exe firefox.exe@0x4033 20 firefox.exe __tmainCRTStartup crtexe.c:594 21 firefox.exe _SEH_epilog4 22 kernel32.dll BaseThreadInitThunk 23 ntdll.dll __RtlUserThreadStart 24 ntdll.dll RtlAllocateMemoryBlockLookaside 25 kernel32.dll LoadStringByReference 26 kernel32.dll LoadStringByReference More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CJSObject%3E%28JSContext*%2C%20js%3A%3Agc%3A%3AAllocKind%2C%20unsigned%20int%29

It's #20 top crasher in 9.0b3.

This is pretty scary ... we're attempting to *execute* garbage memory. Can we get someone to look into this?

The most common execute crashes (more than half of those I looked at) are happening during cycle collector shutdown, when it forces GCs. That seems weird. Here's an example: https://crash-stats.mozilla.com/report/index/35b4cdc7-f333-40dd-9f6f-4523d2111128 Maybe something in JS is getting purged prior to XPCOM shutdown in a way that the GC isn't expecting?

This looks like the usual memory-corruption-like GC crash to me. The exec crashes happen when we try to call a finalizer on a garbage object.

Dave, so you are saying we don't have enough info to do anything? It doesn't make sense to track it then.

#1 topcrash in early 9.0 final data. the particular signature js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int) seems to be only found in fx9 and lower rank in 10 beta. Is it possible there has been some signature shifting in 9 and 10, or is this a regression?

pretty wide distribution of domains and urls, although facebook and yandex seem to tickle this a bit more than other sites domains of sites 46 \N// 41 http://www.facebook.com 33 jar:file:// 27 http://vkontakte.ru 25 about:blank// 22 http://www.yandex.ru 13 http://www.odnoklassniki.ru 12 http://yandex.ru 11 http://vk.com 11 http://clck.yandex.ru 10 https://www.facebook.com 9 https://s-static.ak.fbcdn.net 9 http://www.google.com 5 https://mail.yandex.ru 5 http://e.mail.ru 4 https://services.addons.mozilla.org 4 http://mycomet.mail.ru 4 http://firefox.yandex.ru 4 file:// 3 wyciwyg://11 3 https://plusone.google.com 3 https://apps.facebook.com 3 http://x-torrents.org 3 http://www.rambler.ru 3 http://www.mozilla.com 3 http://www.mamba.ru 3 http://static.ak.facebook.com 3 http://r.mail.ru 3 http://news.yandex.ru 3 http://mail.ru 3 http://images.yandex.ru 3 http://apps.facebook.com 3 bar:tabs//

I looked at another dozen or so reports, and every single one was occurring during shutdown, when the cycle collector triggers a GC before the CC actually runs.

(In reply to Andrew McCreight [:mccr8] from comment #8) > I looked at another dozen or so reports, and every single one was occurring > during shutdown, when the cycle collector triggers a GC before the CC > actually runs. What's the next step in investigation of this top crasher? Can we ask QA to do exploratory testing based upon our current understanding?

[sg:moderate] assuming comment 8 about it only being a shutdown crash is accurate. otherwise this is [sg:critical]. I suspect it's not just a shutdown crash.

There's a high correlation in 9.0.1 with the Yandex bar: 84% (376/448) vs. 7% (7042/101230) yasearch@yandex.ru (Yandex.Bar, https://addons.mozilla.org/addon/3495)

CCing kev for potential yandex outreach.

Kev, can we get someone from Yandex to help with this. There is another Yandex crrelated top crash as well.

Similar 657199?

bug 722101 has a test case.

There's a spike in crashes starting in 15.0a1/20120504122939. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2db9df42823d&tochange=9ebf3dc839c5 It might be related to incremental GC like bug 752098. More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CJSObject%3E%28js%3A%3AFreeOp*%2C+js%3A%3Agc%3A%3AAllocKind%2C+unsigned+int%29

I just went through all the crash comments for all related signatures: * I saw a lot of mentions of closing the browser window or application or clicking between tabs * I also saw a lot of mentions of JS-heavy pages or HTML5 experiment pages (Google Chromes or ours?) * People are seeing this when using Yandex search, Facebook, eBay, PayPal, We should do some exploratory testing with Firefox 15 and the Yandex Bar on Windows 7 with some of the sites I mentioned above.

Crashes in 15.0a1 after the spike are not correlated to Yandex Bar. Here are a few comments: "I was reloading a tab, then I changed to another tab, I used the scroll and suddenly, there was a crash. It´s the second crash in 5 minutes for me." "right after restore bookmark using FEBE"

I get this crash a lot without yandex. Just random surfing around with IGC on.

The spike is probably bug 752098. Let's wait and see if it goes away now that the patch for that has landed.

Has anybody been able to verify if this has gone away? I still see these signatures on the trunk in build id - 20120513030522.

I am able to reproduce this crash in the latest nightly (20120601) with the following steps: 1. Go to a random page and do a Print Preview (Alt-f-v). 2. Hit Escape. 3. Repeat steps 1 and 2 repeatedly (Alt-f-v, Esc, Alt-f-v, Esc), around five times. Make sure you do it quickly. 4. Wait 30 seconds. It should crash.

Thanks for the report. Can you still reproduce if you set javascript.options.mem.gc_incremental to false in about:config?

It's already set to false.

I can't reproduce with the STR in comment 22 and a new profile.

Crashes went away after 15.0a1/20120601. The working range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73783bf75c4c&tochange=5199196b65ec

Fairly low volume now, can probably untrack.

Should this be marked a dupe of bug 770238 now?

It still happens. More reports at: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CJSObject%3E%28js%3A%3AFreeOp*%2C+js%3A%3Agc%3A%3AAllocKind%2C+unsigned+int%29 https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CJSObject%3E%28js%3A%3AFreeOp*%2C+js%3A%3Agc%3A%3AAllocKind%2C+unsigned+__int64%29

not much visible in Thunderbird until version 24.

Only one signature from this report appears in Socorro for Firefox 28 and 29 (the rest stopped a few versions ago): https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CJSObject%3E%28js%3A%3AFreeOp%2A%2C+js%3A%3Agc%3A%3AAllocKind%2C+unsigned+__int64%29&product=Firefox&query_type=contains&range_unit=weeks&process_type=any&hang_type=any&date=2014-01-13+10%3A00%3A00&range_value=4#reports Unfortunately, none of the crash reports have any comments and the reports I opened didn't have add-ons in common either(except the default theme).

This has come back in significant numbers, rising 10 positions to #11 in the Firefox 31 topcrash report. It currently accounts for 0.93% of all crashes in Firefox 31. Unfortunately we still have zero comments and zero correlations. Any advice on how we can debug this further?

Having a sec-moderate rating on a random GC crash permabug isn't really useful, so I'm going to remove the tag. It looks like this is ranked 81 on Fx35 so I'm going to remove the top-crash keyword.

I tried reproducing this with same steps mentioned in comment# 22 with javascript.options.mem.gc_incremental true and false both but didn't encounter crash. I could have tested with Yandex too but it appears corrupt. I tested on window 7 with current released Firefox version 44.0.2 But I see number of crashes here https://crash-stats.mozilla.com/report/list?range_unit=days&range_value=7&signature=js%3A%3Agc%3A%3AArena%3A%3Afinalize%3CT%3E

This is "randomly" crashing for me frequently on Firefox 45.0 on Linux Mint 17.2 64-bit. It was also happening on 44.0.2. Quite sudden, wasn't happening before Unfortunately I do not yet have any useful bug reports because the stack traces have no symbols. Perhaps the Mint developers forgot to upload them to the Mozilla server? In any case, I'll try and get something more useful. I know it's this function though because I compared the address with the address in the symbols from the firefox-dbg package (some manual grepping of nm output yielded this). I do know that this only started happening recently. Hasn't crashed for years and then crashes frequently starting on March 10. But I had been running 44.0.2 for almost a month before that. Anyway, I'll try and get more info.

Also reported in Sumo by a Windows 7 user, with multiple other signatures. Question thread https://support.mozilla.org/en-US/questions/1132057 Included bp-86cb6830-5aa6-41d2-a796-ff8fa2160723 Signature IsObjectKeyAboutToBeFinalized More Reports Search UUID 86cb6830-5aa6-41d2-a796-ff8fa2160723 Date Processed 2016-07-23 10:56:04 Uptime 552 seconds (9 minutes and 12 seconds) Last Crash 555 seconds before submission (9 minutes and 15 seconds) Install Age 3,714,967 seconds since version was first installed (6 weeks, 23 hours and 56 minutes) Install Time 2016-06-10 10:59:25 Product Firefox Version 47.0 Build ID 20160604131506 Release Channel release OS Windows 7 OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 42 stepping 7 | 8 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 User Comments App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x1080, AdapterSubsysID: 15803842, AdapterDriverVersion: 10.18.13.6519 FP(D000-L100000-W00000000-T0000) D2D1.1? DWrite? DWrite+ D2D1.1+ D3D11 Layers? D3D11 Layers+ Processor Notes processor_ip-172-31-32-65_1310; MozillaProcessorAlgorithm2015; skunk_classifier: reject - not a plugin hang EMCheckCompatibility True Adapter Vendor ID 0x10de Adapter Device ID 0x1080 Total Virtual Memory 4,294,836,224 bytes (4 GB) Available Virtual Memory 3,030,319,104 bytes (2.82 GB) System Memory Use Percentage 28 Available Page File 14,294,892,544 bytes (13.31 GB) Available Physical Memory 6,053,806,080 bytes (5.64 GB) Crashing Thread (0) Frame Module Signature Source 0 xul.dll IsObjectKeyAboutToBeFinalized js/src/vm/TypeInference.cpp:796 1 xul.dll SweepArenaList<JSScript, js::AutoClearTypeInferenceStateOnOOM*> js/src/jsgc.cpp:5420 2 xul.dll js::gc::GCRuntime::sweepPhase(js::SliceBudget&) js/src/jsgc.cpp:5461 3 xul.dll js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp:6095 4 xul.dll js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp:6318 5 xul.dll js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) js/src/jsgc.cpp:6424 6 xul.dll js::gc::GCRuntime::gcSlice(JS::gcreason::Reason, __int64) js/src/jsgc.cpp:6497

Crash volume for signature 'js::gc::Arena::finalize<T>': - nightly (version 51): 3 crashes from 2016-08-01. - aurora (version 50): 5 crashes from 2016-08-01. - beta (version 49): 134 crashes from 2016-08-02. - release (version 48): 143 crashes from 2016-07-25. - esr (version 45): 55 crashes from 2016-05-02. Crash volume on the last weeks (Week N is from 08-22 to 08-28): W. N-1 W. N-2 W. N-3 - nightly 0 2 0 - aurora 2 2 0 - beta 46 44 21 - release 42 52 20 - esr 2 1 8 Affected platforms: Windows, Linux Crash rank on the last 7 days: Browser Content Plugin - nightly #536 - aurora #1336 #774 - beta #488 #168 - release #520 #718 - esr #2375

Wontfix for 49. Calixte maybe this is another good example of a bug I don't really want to see suddenly marked affected for beta or release by the bot, #488 crash, also not high on release. Maybe we should care, or the javascript team might add it to a backlog, but I don't even want to triage it while I have a lot to do during beta. (I still love the bot. Just not in this kind of bug during beta!) terrence, do you think there is anything actionable here to fix (not for 49 beta but potentially for 51) My guess would be this is a fairly low volume crasher on beta and release for a long time.

Indeed, this falls into the same generic "heap corruption" bucket that we don't have any good way to triage. Unfortunately, there's nothing useful to be gleaned from the stacks here..

Per comment 39, this bug is inactionable. There is a lot of work being done to improve GC stability in other bugs where the source of the problem is better-understood.