Seen while reviewing crash stats. New crash that started showing up in the 2010121500 build. Links to the all crashes: http://tinyurl.com/25bf3r8 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=66036625795f&tochange=f11f7ed625ba shows the changeset, which is based on what I see in crash stats. Frame Module Signature [Expand] Source 0 xul.dll nsNPAPIPluginInstance::UseAsyncPainting modules/plugin/base/src/nsNPAPIPluginInstance.cpp:879 1 xul.dll nsPluginInstanceOwner::UseLayers layout/generic/nsObjectFrame.cpp:474 2 xul.dll nsPluginInstanceOwner::CallSetWindow layout/generic/nsObjectFrame.cpp:6579 3 xul.dll nsPluginInstanceOwner::UpdateWindowPositionAndClipRect layout/generic/nsObjectFrame.cpp:6569 4 xul.dll nsObjectFrame::ComputeWidgetGeometry layout/generic/nsObjectFrame.cpp:1338 5 xul.dll nsObjectFrame::GetEmptyClipConfiguration layout/generic/nsObjectFrame.h:155 6 xul.dll PluginHideEnumerator layout/base/nsPresContext.cpp:2454 7 xul.dll nsTHashtable<nsPtrHashKey<nsObjectFrame> >::s_EnumStub obj-firefox/dist/include/nsTHashtable.h:420 8 xul.dll PL_DHashTableEnumerate obj-firefox/xpcom/build/pldhash.c:754 9 mozcrt19.dll malloc obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:5873 10 xul.dll nsObjectFrame::GetEmptyClipConfiguration layout/generic/nsObjectFrame.h:156 11 @0x3b

There is a spike in crashes from 4.0b9pre/20101220. It is #7 top crasher in this build. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be8006fc9c4a&tochange=fc50c521bf48 According to that, it seems that is a Layout issue and not a Plug-ins one. More reports at (without a limit date as in comment 0): http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsNPAPIPluginInstance%3A%3AUseAsyncPainting%28int*%29)

Bug 617152 is the obvious candidate. It's not clear from the stack which of the various members is corrupted.

It must be this changeset: http://hg.mozilla.org/mozilla-central/rev/e9f317c9ab52 It added the call to mInstanceOwner->UseLayers() which is crashing here. But why would it crash? That doesn't make sense to me.

Hmm, actually the stacks show lots of paths to UseLayers crashing, not just the one added in that changeset.

They also show lots of crashes in UseAsyncPainting before my stuff landed, so it looks to me like the extra call I added simply made an existing bug worse.

nsNPAPIPluginInstance::UseAsyncPainting is virtual so it's unlikely nsNPAPIPluginInstance is corrupt. Could mPlugin or mPlugin->mLibrary be a non-null dangling pointer?

I'm hopeful that one or both of those patches will effectively work around the bug.

Part 1: http://hg.mozilla.org/mozilla-central/rev/a05e91710adb

Spike looks fixed: http://crash-stats.mozilla.com/report/list?product=Firefox&branch=2.0&query_search=signature&query_type=exact&query=nsNPAPIPluginInstance%3A%3AUseAsyncPainting%28int*%29&date=01%2F02%2F2011%2016%3A42%3A03&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsNPAPIPluginInstance%3A%3AUseAsyncPainting%28int*%29 Only one crash in a build later than 12/23. Fixed per https://bugzilla.mozilla.org/show_bug.cgi?id=620794#c4.

Part 1 is still a good patch. Part 2 is probably unnecessary complexity.

As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)

The spike described in comment 1 has been fixed by the part-1 patch. But it still happens. It is #95 top crasher in 4.0b11. Comments talk mainly about Webex. More reports at: https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=4&range_unit=weeks&signature=nsNPAPIPluginInstance%3A%3AUseAsyncPainting%28int*%29

WebEx is known to crash on OSX ... is that the primary OS where we're seeing crashes? Not a blocker at this point.

> WebEx is known to crash on OSX ... is that the primary OS where we're seeing > crashes? Crashes happen only on Windows.

Only 5 crash reports in the past 6 months, all in Firefox v15 or older.