crash in js::gc::IsAboutToBeFinalized<js::types::TypeObject>

RESOLVED FIXED

Status

()

defect
--
critical
RESOLVED FIXED
5 years ago
Last year

People

(Reporter: tracy, Assigned: terrence)

Tracking

({crash, topcrash-win})

33 Branch
x86
Windows NT
Points:
---

Firefox Tracking Flags

(firefox33+ wontfix, firefox34+ fixed, firefox35 fixed, firefox36 fixed)

Details

(crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

This bug was filed from the Socorro interface and is 
report bp-19e8f104-4744-4670-962c-3b2c82141005.
=============================================================

[Tracking Requested - why for this release]:

This was around in the 33betas in low numbers. But has spiked in volume on 33.0rc. elevating it to #14 on the 7 day topcrash list

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::gc::IsAboutToBeFinalized<js::types::TypeObject> 	js/src/gc/Marking.cpp
1 	mozjs.dll 	JSCompartment::sweepCrossCompartmentWrappers() 	js/src/jscompartment.cpp
2 	mozjs.dll 	JSCompartment::sweep(js::FreeOp*, bool) 	js/src/jscompartment.cpp
3 	mozjs.dll 	js::gc::GCRuntime::beginSweepingZoneGroup() 	js/src/jsgc.cpp
4 	mozjs.dll 	js::gc::GCRuntime::sweepPhase(js::SliceBudget&) 	js/src/jsgc.cpp
5 	mozjs.dll 	js::gc::GCRuntime::incrementalCollectSlice(__int64, JS::gcreason::Reason, js::JSGCInvocationKind) 	js/src/jsgc.cpp
6 	mozjs.dll 	js::gc::GCRuntime::gcCycle(bool, __int64, js::JSGCInvocationKind, JS::gcreason::Reason) 	js/src/jsgc.cpp
7 	mozjs.dll 	js::gc::GCRuntime::collect(bool, __int64, js::JSGCInvocationKind, JS::gcreason::Reason) 	js/src/jsgc.cpp
8 	mozjs.dll 	js::gc::GCRuntime::gcSlice(js::JSGCInvocationKind, JS::gcreason::Reason, __int64) 	js/src/jsgc.cpp
9 	mozjs.dll 	js::GCSlice(JSRuntime*, js::JSGCInvocationKind, JS::gcreason::Reason, __int64) 	js/src/jsgc.cpp
10 	mozjs.dll 	JS::IncrementalGC(JSRuntime*, JS::gcreason::Reason, __int64) 	js/src/jsfriendapi.cpp
11 	xul.dll 	nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, __int64) 	dom/base/nsJSEnvironment.cpp
12 	xul.dll 	InterSliceGCTimerFired(nsITimer*, void*) 	dom/base/nsJSEnvironment.cpp
13 	xul.dll 	nsTimerImpl::Fire() 	xpcom/threads/nsTimerImpl.cpp
14 	xul.dll 	nsTimerEvent::Run() 	xpcom/threads/nsTimerImpl.cpp
15 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
16 	gkmedias.dll 	patch_transient_decision 	media/libopus/celt/celt_encoder.c
17 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
18 	xul.dll 	nsBaseAppShell::Run() 	widget/xpwidgets/nsBaseAppShell.cpp
19 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp
20 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp
21 	xul.dll 	xul.dll@0x15ca327 	
22 		@0x101ae9f 	
23 	xul.dll 	nsAString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) 	xpcom/string/nsTSubstring.cpp
24 	xul.dll 	nsAString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) 	xpcom/string/nsTSubstring.cpp
25 	xul.dll 	nsAString_internal::ReplacePrep(unsigned int, unsigned int, unsigned int) 	xpcom/string/nsTSubstring.h
26 	mozglue.dll 	arena_malloc 	memory/mozjemalloc/jemalloc.c
27 	mozglue.dll 	je_malloc 	memory/mozjemalloc/jemalloc.c
28 	xul.dll 	xul.dll@0x17ffff 	
29 	xul.dll 	std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Tidy(bool, unsigned int) 	c:/program files (x86)/microsoft visual studio 10.0/vc/include/xstring:1996
30 	xul.dll 	`anonymous namespace'::HistogramGet(char const*, char const*, unsigned int, unsigned int, unsigned int, unsigned int, base::Histogram**) 	toolkit/components/telemetry/Telemetry.cpp
31 	kernel32.dll 	GetLocaleInfoA 	
32 	xul.dll 	mozilla::Telemetry::Accumulate(mozilla::Telemetry::ID, unsigned int) 	toolkit/components/telemetry/Telemetry.cpp
33 	firefox.exe 	NS_internal_main(int, char**) 	browser/app/nsBrowserApp.cpp
34 	xul.dll 	mozilla::layers::FillRectWithMask(mozilla::gfx::DrawTarget*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::SourceSurface*, mozilla::gfx::Filter, mozilla::gfx::DrawOptions const&, mozilla::gfx::ExtendMode, mozilla::gfx::SourceSurface*, mozilla::gfx::Matrix const*, mozilla::gfx::Matrix const*) 	gfx/layers/basic/BasicLayersImpl.cpp
35 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
36 	firefox.exe 	_crt_debugger_hook 	
37 	kernel32.dll 	BaseProcessStart
|thing| is null at IsAboutToBeFinalized.

It's kind of erratic. The spike might just be part of ebb and flow, but on the other hand, the 10/07 build is highest even with the least exposure time. Beta channel crashes by build since 9/18:
20140918174809 	1263
20140922173023 	382
20140923222114 	1596
20140929180120 	864
20141002185629 	1410
20141007073543 	1867
Tracking in case we make a dot release and we have a potential fix for this.

Do we know if 34 is affected?
> Do we know if 34 is affected?
Yes. It's also worth noting that this signature has many friends that can be interchanged by the compiler from build to build. I'm adding the variations that we've seen so far, but there may be new ones in the future.

Combining all the "IsAboutToBeFinalized" signatures:
32.0.3, this is about 0.3% of crashes in the past week
33.0b: 1.47%
34.0a2: 1.11%
35.0a1: none, although there is a new signature "IsAboutToBeFinalizedFromAnyThread" that is very low volume
Crash Signature: [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] → [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalized<JSScript>] [@ js::gc::IsAboutToBeFinalized<JSFunction>] [@ js::gc::IsAboutToBeFinalized<js::ScopeObject>]
[Tracking Requested - why for this release]:
#5 top crash for 34.0b1, as js::gc::IsAboutToBeFinalized<js::types::TypeObject>, with 1321/36533 crashes.
Not a fix, but a diagnostic that may give us something useful if it occurs on try.
Assignee: nobody → terrence
Status: NEW → ASSIGNED
Attachment #8508957 - Flags: review?(wmccloskey)
Comment on attachment 8508957 [details] [diff] [review]
do_not_allow_null_xcompartment_keys-v0.diff

Review of attachment 8508957 [details] [diff] [review]:
-----------------------------------------------------------------

Please make these all MOZ_RELEASE_ASSERTs. This isn't hot code.
Attachment #8508957 - Flags: review?(wmccloskey) → review+
Excellent! Looks green for debug on try too, so this is ready to check in as soon as the trees open back up.

https://tbpl.mozilla.org/?tree=Try&rev=58f1834d3b20
Attachment #8508957 - Attachment is obsolete: true
Attachment #8509952 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/50a35da22abf
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
This has now been on m-c for 6 days. Can you please request Beta and Aurora approval?
Flags: needinfo?(terrence)
Thanks for the poke.
Status: RESOLVED → REOPENED
Flags: needinfo?(terrence)
Resolution: FIXED → ---
Keywords: leave-open
Comment on attachment 8509952 [details] [diff] [review]
do_not_allow_null_xcompartment_keys-vCheckin.diff

Approval Request Comment
[Feature/regressing bug #]: Unknown.
[User impact if declined]: This is a diagnostic patch, so unknown. Only positive things can come of it though as it's just asserting invariants.
[Describe test coverage new/current, TBPL]: A week on TBPL.
[Risks and why]: Low. At worst, we'll crash in a safe way instead of in the GC. At best, we'll identify the buggy code so we can fix it. 
[String/UUID change made/needed]: None.
Attachment #8509952 - Flags: approval-mozilla-beta?
Attachment #8509952 - Flags: approval-mozilla-aurora?
Comment on attachment 8509952 [details] [diff] [review]
do_not_allow_null_xcompartment_keys-vCheckin.diff

Beta+
Aurora+
Attachment #8509952 - Flags: approval-mozilla-beta?
Attachment #8509952 - Flags: approval-mozilla-beta+
Attachment #8509952 - Flags: approval-mozilla-aurora?
Attachment #8509952 - Flags: approval-mozilla-aurora+
I don't think we are going to have a patch for this in the next few days for 33.1. Wontfix then.
Crash Signature: [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalized<JSScript>] [@ js::gc::IsAboutToBeFinalized<JSFunction>] [@ js::gc::IsAboutToBeFinalized<js::ScopeObject>] → [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalized<JSScript>] [@ js::gc::IsAboutToBeFinalized<JSFunction>] [@ js::gc::IsAboutToBeFinalized<js::ScopeObject>] [@ js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>]
In 34.0b5, this seems to have changed to js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>, see https://crash-stats.mozilla.com/report/list?signature=js%3A%3Agc%3A%3AIsAboutToBeFinalized%3Cjs%3A%3AUnownedBaseShape%3E
Crash Signature: [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalized<JSScript>] [@ js::gc::IsAboutToBeFinalized<JSFunction>] [@ js::gc::IsAboutToBeFinalized<js::ScopeObject>] [@ js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>] → [@ js::gc::IsAboutToBeFinalized<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalized<JSScript>] [@ js::gc::IsAboutToBeFinalized<JSFunction>] [@ js::gc::IsAboutToBeFinalized<js::ScopeObject>] [@ js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>] […
This was the #7 topcrasher for 34.0b7. It's not showing up yet for 34.0b8.  

Terrence, should I file a new bug based on 34.0b7 crashes with its new signature, and close this one? Or wait until we have more results from beta 8?
Flags: needinfo?(terrence)
(In reply to Liz Henry :lizzard from comment #18)
> This was the #7 topcrasher for 34.0b7. It's not showing up yet for 34.0b8.  
> 
> Terrence, should I file a new bug based on 34.0b7 crashes with its new
> signature, and close this one? Or wait until we have more results from beta
> 8?

This set of templates has an identical body, so the compiler will coalesce them into a single definition. Unfortunately, most compilers hand out the first name they see for the definition, so it's going to shift around with random build changes, unrelated code changes, compiler version bumps and whatnot. I'd suggest keeping this bug and changing the signature as needed so that the information is at least in one place.
Flags: needinfo?(terrence)
Let's add the signatures to the list in this bug then, yes.
This is now the #5 topcrasher for 34.0b11, 1.13% of crashes.
Crash Signature: js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>] [@ js::gc::IsAboutToBeFinalizedFromAnyThread<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalizedFromAnyThread<js::NestedScopeObject>] → js::gc::IsAboutToBeFinalized<js::UnownedBaseShape>] [@ js::gc::IsAboutToBeFinalizedFromAnyThread<js::types::TypeObject>] [@ js::gc::IsAboutToBeFinalizedFromAnyThread<js::NestedScopeObject>] [@ js::gc::IsAboutToBeFinalized<T>] [@ js::gc::IsAboutToBeFi…
Not top 50 crash for any current Firefox desktop release or beta afaict.
Seems to have been solved.
Status: REOPENED → RESOLVED
Closed: 5 years ago3 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Duplicate of this bug: 1038807
You need to log in before you can comment on or make changes to this bug.