635191 - Crash [@ nsObjectFrame::GetImageContainer(mozilla::layers::LayerManager*) ]

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Scoobidiver (away)]

It is a new crash signature that first appeared in 4.0b12pre/20110213.
There is a spike in crashes from 4.0b12pre/20110217.
It is #10 top crasher in this build.
The crashes in 4.0b11 have a different stack trace.

One comment says: "I was entering web sites into speed dial. After I had gotten about five sites in , Firefox crashed."

Signature	nsObjectFrame::GetImageContainer(mozilla::layers::LayerManager*)
UUID	784ea707-cc46-4f28-9c4d-deaad2110217
Time 	2011-02-17 22:13:03.538782
Uptime	84
Last Crash	67 seconds before submission
Install Age	246 seconds (4.1 minutes) since version was first installed.
Product	Firefox
Version	4.0b12pre
Build ID	20110217123853
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x14
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 2a42, AdapterDriverVersion: 8.15.10.1855

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsObjectFrame::GetImageContainer 	layout/generic/nsObjectFrame.cpp:1929
1 	xul.dll 	nsPluginInstanceOwner::IsUpToDate 	layout/generic/nsObjectFrame.cpp:497
2 	xul.dll 	nsPluginInstanceOwner::InvalidateRect 	layout/generic/nsObjectFrame.cpp:3461
3 	xul.dll 	nsNPAPIPluginInstance::InvalidateRect 	modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1201
4 	xul.dll 	mozilla::plugins::parent::_invalidaterect 	modules/plugin/base/src/nsNPAPIPlugin.cpp:1268
5 	xul.dll 	mozilla::plugins::PluginInstanceParent::RecvNPN_InvalidateRect 	dom/plugins/PluginInstanceParent.cpp:493
6 	xul.dll 	mozilla::plugins::PluginInstanceParent::RecvShow 	dom/plugins/PluginInstanceParent.cpp:553
7 	xul.dll 	mozilla::plugins::PPluginInstanceParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PPluginInstanceParent.cpp:1068
8 	xul.dll 	mozilla::plugins::PPluginModuleParent::OnMessageReceived 	obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:740
9 	xul.dll 	mozilla::ipc::SyncChannel::OnDispatchMessage 	ipc/glue/SyncChannel.cpp:169
10 	xul.dll 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:431
11 	xul.dll 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:343
12 	xul.dll 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:351
13 	xul.dll 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:451
14 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:114
15 	xul.dll 	xul.dll@0xb337ab 	
16 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
17 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
18 	mozcrt19.dll 	_VEC_memzero 	
19 	xul.dll 	xul.dll@0x35d2dd 	
20 	firefox.exe 	firefox.exe@0x1bb7 	
21 	ntdll.dll 	LdrpGetShimEngineInterface 	
22 	ntdll.dll 	_RtlUserThreadStart 	
23 	firefox.exe 	firefox.exe@0x186f 	
24 	firefox.exe 	firefox.exe@0x186f

The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9698ac3f1c61&tochange=51702867d932
The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b4aa47ca42c1&tochange=4b9e814fe3ab

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=4&range_unit=weeks&signature=nsObjectFrame%3A%3AGetImageContainer%28mozilla%3A%3Alayers%3A%3ALayerManager*%29

Comment 1

[Sheila Mooney]

This is something new that appeared on Feb 17th. It was #3 on the list yesterday for Windows crashes, #2 non-plugin related one. Probably should be looked at.

Comment 2

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

cjones - can you look at this? regression from your recent changes? If it turns out that's not the case, we can drop it off the list, but all signs point to you! :)

Comment 3

[Benjamin Smedberg]

This is a really weird crash, FWIW. The crashing line:

http://hg.mozilla.org/mozilla-central/annotate/8812253737ce/layout/generic/nsObjectFrame.cpp#l1929

  manager = nsContentUtils::LayerManagerForDocument(mContent->GetOwnerDoc());

Doesn't leave a lot of room for what can be wrong: mContent could be null, I guess...?

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Oops, mid-aired saying something similar.

Timothy/Rob, does anything guarantee this being non-null?  Is an object frame staying alive too long or something?

Band-aid patch is simple enough.

Comment 5

[Mike Shaver (:shaver emeritus)]

I saw this when I was closing a bunch of tabs in rapid succession, many of which had Flash banner ads.  Dunno if that's helpful. bp-220e67d8-b62f-463c-906b-47f032110218

Comment 6

[Bill Gianopoulos [:WG9s]]

(In reply to comment #3)
> This is a really weird crash, FWIW. The crashing line:
> 
> http://hg.mozilla.org/mozilla-central/annotate/8812253737ce/layout/generic/nsObjectFrame.cpp#l1929
> 
>   manager = nsContentUtils::LayerManagerForDocument(mContent->GetOwnerDoc());
> 
> Doesn't leave a lot of room for what can be wrong: mContent could be null, I
> guess...?

So, perhaps change the if condition, in the previous line, to:

if (!manager && mContent) {

?

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: If the object frame has gone away, there's no way to determine IsUpToDate(), so just dispatch the paint-finished event

After many laborious minutes of watching videos and playing flash games, I was never able to reproduce this.  However, through some buddy-debugging with Timothy and Ehsan, we came up with this solution.

Comment 8

[Mike Shaver (:shaver emeritus)]

Is this ready to land?

Comment 9

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

Comment on attachment 513636 [details] [diff] [review]
If the object frame has gone away, there's no way to determine IsUpToDate(), so just dispatch the paint-finished event

Yes

Comment 10

[Mounir Lamouri (:mounir)]

Pushed:
http://hg.mozilla.org/mozilla-central/rev/e4b9604fdba5