#17 topcrash for TB17.0.2 caused by GC/IGC? induced by addon(s)? I suspect there are multiple causes, but the huge crash rate increase mentioned below would indicate there must be one or a couple big issues, and it may take multiple people to figure it out. What I can say is: - I didn't find clear correlations, but perhaps choffman or others can double check? - Mac crash uptick at TB14, XPCWrappedNative::FlatJSObjectFinalized. But not XPCWrappedNative::FlatJSObjectFinalized() - in TB15.0.1 (20120907 build) big uptick in XPCWrappedNative::FlatJSObjectFinalized() which continued in TB16.0.1 - in TB16.0.2 (20121026 build) crashes roughly doubled - crash rate in TB17.* continues at about same high rate - I haven't figured out anything yet from crash reporters This bug was filed from the Socorro interface and is report bp-9f947822-109a-4d16-bd13-f26102130128 . ============================================================= 0 xul.dll XPCWrappedNative::FlatJSObjectFinalized js/xpconnect/src/XPCWrappedNative.cpp:1317 1 xul.dll WrappedNativeFinalize js/xpconnect/src/XPCWrappedNativeJSOps.cpp:617 2 xul.dll XPC_WN_NoHelper_Finalize js/xpconnect/src/XPCWrappedNativeJSOps.cpp:623 3 mozjs.dll js::gc::Arena::finalize<JSObject> js/src/jsgc.cpp:348 4 mozjs.dll js::gc::FinalizeTypedArenas<JSObject> js/src/jsgc.cpp:412 5 mozjs.dll js::gc::ArenaLists::queueObjectsForSweep js/src/jsgc.cpp:1722 6 mozjs.dll BeginSweepPhase js/src/jsgc.cpp:3750 7 mozjs.dll IncrementalCollectSlice js/src/jsgc.cpp:4217 8 mozjs.dll GCCycle js/src/jsgc.cpp:4395 9 mozjs.dll Collect js/src/jsgc.cpp:4503 10 mozjs.dll js::GCSlice js/src/jsgc.cpp:4541 11 mozjs.dll js::IncrementalGC js/src/jsfriendapi.cpp:171 bp-34dbc989-acf9-40db-9d05-9295d2130121 TB19 beta bp-a172fff9-6731-47b9-839f-779562130118 "I was moving to many messages." bp-4bd3d70b-aa7b-428d-86f2-88f622121227 TB18 beta bp-a45e3b5a-db28-4bc9-a2ae-a3d822130128 TB17.0.2

I'm not sure why the spike happened or why the spike is gone, but TB17.0.4 rank is #53 and TB17.0.5 rank is #70. Perhaps it coincides with Firefox 20 crash rate being half of the Firefox 19 rate? Rate for FF21 seems to be headed for the same level of FF20. bp-7d25d7e1-0d3a-46a2-a267-54dde2130226 Thunderbird linux 0 libxul.so XPCWrappedNative::FlatJSObjectFinalized nsISupportsUtils.h:149 1 libxul.so WrappedNativeFinalize XPCWrappedNativeJSOps.cpp:617 2 libxul.so js::gc::Arena::finalize<JSObject> jsobjinlines.h:235 3 libxul.so js::gc::FinalizeArenas jsgc.cpp:412 4 libxul.so IncrementalCollectSlice jsgc.cpp:1626 5 libxul.so GCCycle jsgc.cpp:4395 6 libxul.so Collect jsgc.cpp:4503 7 libxul.so js::IncrementalGC jsfriendapi.cpp:171 8 libxul.so nsJSContext::GarbageCollectNow nsJSEnvironment.cpp:2955

(In reply to Wayne Mery (:wsmwk) from comment #2) > I'm not sure why the spike happened or why the spike is gone, but TB17.0.4 > rank is #53 and TB17.0.5 rank is #70. I don't see any difference between ranks: #21 crasher in TB 17.0.4 over the last four weeks and #16 in TB 17.0.5 over the last week.

This looks like OOM. Most of the crashes are null derefs and have low available memory. I hit this crash while simulating low memory conditions.

This is shown to be rising in KaiRo's explosiveness report over the last few days. Looking at crashstats, this is up 133 positions to #65, accounting of 0.18% of our crashes. It's still low volume but something we might want to keep an eye on if it continues to rise.

(In reply to David Major [:dmajor] from comment #4) > This looks like OOM. Most of the crashes are null derefs and have low > available memory. I hit this crash while simulating low memory conditions. Were you looking at Firefox crashes? Or Thunderbird. I can't speak to the Thunderbird crashes at that time, but currently if these recent TB samples representative then are the majority OOM? bp-956ee534-bd01-43f6-bc70-dce062140809 bp-99428a6a-ae22-41c3-ae28-86d302140809 bp-4abc0fe5-b9f2-430c-8e76-4fbff2140810 bp-d9743c93-70f3-44c8-8f8e-9379a2140808 bp-f1b694e8-f9bc-467f-9d5f-511e12140812 bp-d401a01e-ab97-4e03-92bd-7f38c2140812 bp-94895a2f-43a8-439f-ba89-2025d2140807 all of the above have reporter email address

digging further, I had filed this bug for thunderbird as alternative to bug 608217

(In reply to Wayne Mery (:wsmwk) from comment #6) > (In reply to David Major [:dmajor] from comment #4) > > This looks like OOM. Most of the crashes are null derefs and have low > > available memory. I hit this crash while simulating low memory conditions. > > Were you looking at Firefox crashes? Or Thunderbird. My local experiments were on Firefox. It seems there's a big difference between the two products. FF crashes [1] are low on virtual memory (<250mb) and are mostly null pointers. That sounds a lot like OOM. On the other hand the TB crashes [2] have tons of free memory and relatively few null pointers. Same for the reports that you linked, they don't look like OOMs. [1] https://crash-stats.mozilla.com/search/?signature=%3DXPCWrappedNative%3A%3AFlatJSObjectFinalized%28%29&product=Firefox&_facets=signature&_columns=signature&_columns=product&_columns=version&_columns=available_virtual_memory&_columns=address [2] https://crash-stats.mozilla.com/search/?signature=%3DXPCWrappedNative%3A%3AFlatJSObjectFinalized%28%29&product=Thunderbird&_facets=signature&_columns=signature&_columns=product&_columns=version&_columns=available_virtual_memory&_columns=address

Doesn't seem likely we're going to find a useful regression range for this bug at this point, but feel free to add it back if you feel otherwise.

One user reported bad RAM. I think some of the others may be mail filter related. More digging to come.