Closed Bug 702531 Opened 13 years ago Closed 8 years ago

Crash in js::gc::Arena::finalize<JSObject>

Categories

(Core :: JavaScript: GC, defect)

Product:
Core
Component:
JavaScript: GC
Version:
9 Branch
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox9 + ---
firefox10 + ---
firefox15 - ---
firefox48 --- wontfix
firefox49 --- wontfix
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, testcase-wanted, Whiteboard: [tbird crash])

Crash Data

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.
Crash Signature: [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int)] → [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64)]
No longer depends on: 681884
Hardware: x86 → All
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.
tracking-firefox10: --- → ?
Dave, so you are saying we don't have enough info to do anything? It doesn't make sense to track it then.
Keywords: topcrash
Crash Signature: [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64)] → [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned int bo…
Crash Signature: bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] → bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] [@ je_free | js::gc::Arena::finalize<JSString>(JSContext*, js::gc::AllocKind, unsigned int)]
#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?
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?
Keywords: sec-review-needed
[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.
Keywords: testcase-wanted
Whiteboard: [sg:moderate]
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)
Summary: Crash in js::gc::Arena::finalize → Crash in js::gc::Arena::finalize (mainly correlated to Yandex.Bar)
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
Crash Signature: bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] [@ je_free | js::gc::Arena::finalize<JSString>(JSContext*, js::gc::AllocKind, unsigned int)] → bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] [@ je_free | js::gc::Arena::finalize<JSString>(JSContext*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(js::FreeOp* js::gc::Al…
tracking-firefox15: --- → ?
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.
tracking-firefox15: ? → +
Keywords: qawanted
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.
Depends on: 752098
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.
Keywords: topcrash
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
Crash Signature: , bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] [@ je_free | js::gc::Arena::finalize<JSString>(JSContext*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc:… → , bool)] [@ js::gc::Arena::finalize<JSObject>(JSContext*, js::gc::AllocKind, unsigned __int64, bool)] [@ js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc::AllocKind, unsigned int)] [@ js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc::AllocKin…
Summary: Crash in js::gc::Arena::finalize (mainly correlated to Yandex.Bar) → Crash in js::gc::Arena::finalize<JSObject>
not much visible in Thunderbird until version 24.
Whiteboard: [sg:moderate] → [sg:moderate][tbird crash]
Blocks: 843074
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).
Keywords: qawanted
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?
Keywords: topcrash-win
Assignee: general → nobody
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.
Component: JavaScript Engine → JavaScript: GC
Keywords: sec-moderate, topcrash-win
Whiteboard: [sg:moderate][tbird crash] → [tbird crash]
Crash Signature: , js::gc::AllocKind, unsigned __int64)] → , js::gc::AllocKind, unsigned __int64)] [@ js::gc::Arena::finalize<T>]
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
status-firefox48: --- → affected
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox-esr45: --- → affected
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.
status-firefox48: affected → wontfix
status-firefox49: affected → wontfix
Flags: needinfo?(terrence)
Flags: needinfo?(cdenizet)
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..
Flags: needinfo?(terrence)
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(cdenizet)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.