Closed Bug 635191 Opened 9 years ago Closed 9 years ago

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


(Core :: Layout, defect, critical)

Not set



Tracking Status
blocking2.0 --- betaN+


(Reporter: scoobidiver, Assigned: cjones)


(Keywords: crash, regression, Whiteboard: [hardblocker])

Crash Data


(1 file)

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 Address	0x14
App Notes 	AdapterVendorID: 8086, AdapterDeviceID: 2a42, AdapterDriverVersion:

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/
12 	xul.dll 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/
13 	xul.dll 	MessageLoop::DoWork 	ipc/chromium/src/base/
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/
17 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/
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:
The regression range for the spike is:

More reports at:*%29
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.
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! :)
blocking2.0: ? → betaN+
Whiteboard: [hardblocker]
This is a really weird crash, FWIW. The crashing line:

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

Doesn't leave a lot of room for what can be wrong: mContent could be null, I guess...?
Assignee: nobody → jones.chris.g
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.
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
(In reply to comment #3)
> This is a really weird crash, FWIW. The crashing line:
>   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) {

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.
Attachment #513636 - Flags: review?(roc)
Whiteboard: [hardblocker] → [hardblocker][has patch]
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

Attachment #513636 - Flags: approval2.0+
Closed: 9 years ago
Keywords: checkin-needed
OS: Windows 7 → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [hardblocker][has patch] → [hardblocker]
Target Milestone: --- → mozilla2.0b12
Crash Signature: [@ nsObjectFrame::GetImageContainer(mozilla::layers::LayerManager*) ]
You need to log in before you can comment on or make changes to this bug.