620512 - Firefox 4.0b9pre crash in [@ nsNPAPIPluginInstance::UseAsyncPainting(int*) ]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[Scoobidiver (away)]

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)

Comment 2

[Benjamin Smedberg]

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

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 1: Only fire MozPaintWait and change window visibi lity in BuildDisplayList if we're painting

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Part 2: Cache UseLayers result to avoid having to call into UseAsyncPainting when it might be unsafe

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 10

[Phil Ringnalda (:philor)]

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

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 13

[LegNeato]

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)

Comment 14

[Scoobidiver (away)]

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

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

WebEx is known to crash on OSX ... is that the primary OS where we're seeing crashes?

Not a blocker at this point.

Comment 16

[Scoobidiver (away)]

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

Comment 17

[Mats Palmgren (inactive)]

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