1045992 - crash in mozilla::CycleCollectedJSRuntime::DeferredFinalize(nsISupports*)

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Nils Ohlmeier [:drno]]

This bug was filed from the Socorro interface and is 
report bp-917d7a39-bbdb-4712-ae91-98f332140730.
=============================================================

Comment 2

[(no longer active)]

Just got this: https://crash-stats.mozilla.com/report/index/f54e60c2-ff47-4e26-af8e-341972150925

Comment 3

[Dirkjan Ochtman (:djc)]

Still happening: https://crash-stats.mozilla.com/report/index/a2f8ecfa-2e87-4bc5-9200-308152160130

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

And again: https://crash-stats.mozilla.com/report/index/6305f84f-8520-4f16-aa93-023892160229

Terrence/Jon: Do you happen to be able to know what is going on here? GC seems to be on the stack.

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This signature is essentially "generic memory corruption"

Comment 6

[Terrence Cole [:terrence]]

What Kyle said. This stack has at least 3 compartments and is finalizing something in XPConnect (which is only marginally compartment aware), so it's scary, but there's not much more I can tell you without being able to reproduce it at will, or getting lucky and catching it in rr.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'mozilla::CycleCollectedJSRuntime::DeferredFinalize':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 1 crash from 2016-06-07.
 - beta    (version 48): 5 crashes from 2016-06-06.
 - release (version 47): 11 crashes from 2016-05-31.
 - esr     (version 45): 458 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora           0          0          0          1          0          0          0
 - beta             1          0          2          0          2          0          0
 - release          1          4          0          1          1          1          1
 - esr             48         42         40         43         43         42         29

Affected platforms: Windows, Mac OS X

Comment 14

[Andrew McCreight [:mccr8]]

The signature for this has changed again.

Comment 16

[Wayne Mery (:wsmwk)]

Firefox mozilla::SegmentedVector<T>::PopLastN bp-b119c757-62b4-49db-85b6-46fdd0210829 (not my crash)

Also, #19 crash for Thunderbird 91.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #16)

Firefox mozilla::SegmentedVector<T>::PopLastN bp-b119c757-62b4-49db-85b6-46fdd0210829 (not my crash)

Also, #19 crash for Thunderbird 91.

Now #10 for Thunderbird 91. Is there anything of value?
bp-8308307a-55a5-408f-9bcc-8adda0211012 (Mac)
bp-3c81e9ad-5036-4dc2-89da-6e4be0211011 (windows)

Comment 18

[Wayne Mery (:wsmwk)]

A Mac user reports "Thunderbirds crashes with BCC email alias in Mac address book" https://support.mozilla.org/en-US/questions/1352598
bp-380edefc-5c8c-4c9d-a149-9806a0211003
0 XUL nsArrayBase::QueryElementAt(unsigned int, nsID const&, void**) xpcom/ds/nsArray.cpp:58
1 XUL nsQueryArrayElementAt::operator()(nsID const&, void**) const xpcom/ds/nsArrayUtils.cpp:14
2 XUL nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) xpcom/base/nsCOMPtr.cpp:109
3 XUL nsAbOSXDirectory::GetChildNodes(nsTArray<RefPtr<nsIAbDirectory> >&) comm/mailnews/addrbook/src/nsAbOSXDirectory.mm:616
4 XUL nsMsgCompose::GetABDirAndMailLists(nsTSubstring<char> const&, nsCOMArray<nsIAbDirectory>&, nsTArray<nsMsgMailList>&) comm/mailnews/compose/src/nsMsgCompose.cpp:4267
5 XUL nsMsgCompose::GetABDirAndMailLists(nsTSubstring<char> const&, nsCOMArray<nsIAbDirectory>&, nsTArray<nsMsgMailList>&) comm/mailnews/compose/src/nsMsgCompose.cpp:4256
6 XUL nsMsgCompose::LookupAddressBook(nsTArray<nsMsgRecipient> (&) [3]) comm/mailnews/compose/src/nsMsgCompose.cpp:4428
7 XUL nsMsgCompose::ExpandMailingLists() comm/mailnews/compose/src/nsMsgCompose.cpp:4513
8 XUL NS_InvokeByIndex
9 @0x11e122fff
10 XUL XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp:1143

Comment 19

[Magnus Melin [:mkmelin]]

https://searchfox.org/comm-central/rev/a47e2023ab1c1c824b48d247caed381bc4e4cd20/mailnews/addrbook/src/nsAbOSXDirectory.mm#616
Same situation as bug 1718862 (bug 1718862 comment 4 applies?). Wayne, did you mean comment 18 for bug 1718862? Seems different from what this bug is about.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #19)

https://searchfox.org/comm-central/rev/a47e2023ab1c1c824b48d247caed381bc4e4cd20/mailnews/addrbook/src/nsAbOSXDirectory.mm#616
Same situation as bug 1718862 (bug 1718862 comment 4 applies?). Wayne, did you mean comment 18 for bug 1718862? Seems different from what this bug is about.

I guess so.

Comment 22

[BugBot [:suhaib / :marco/ :calixte]]

Copying crash signatures from duplicate bugs.

Comment 23

[Andrew McCreight [:mccr8]]

The PopLastN signatures should turn into [@ mozilla::SegmentedVector<T>::PopLastN | mozilla::dom::DeferredFinalizerImpl<T>::DeferredFinalize ] once the signature updates get deployed.

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

I think the ReleaseObjects crashes are part of the same...

Comment 25

[Jens Stutte [:jstutte]]

Should this be moved to the Cycle Collector component?

Comment 26

[Andrew McCreight [:mccr8]]

No, DOM is the right component. Deferred finalization is related to the way DOM objects exposed to JS interact with the JS garbage collector, not the cycle collector. (CycleCollectedJSRuntime should probably be renamed something like GeckoJSRuntime, as there is now a lot of extra browser stuff tacked on, not just cycle collection.)

Comment 27

[Andrew McCreight [:mccr8]]

To expand on that, the idea of the deferred finalizer is that when a JS reflector object is destroyed by the JS GC, that can cause the last release of a C++ object, which would cause us to destroy the object and run the destructor. C++ destructors can do all sorts of weird things, and the JS GC is a somewhat sanitized environment, so instead of running the final release during the GC finalization process, we stick strong references on a runnable and wait until after the GC is over to do the releases.