546301 - crash [@ nsView::DoResetWidgetBounds(int, int)]

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Wayne Mery (:wsmwk)]

crash [@ nsView::DoResetWidgetBounds(int, int)]

I encountered this doing File|compact folders, after empty trash
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2pre) Gecko/20100121 Lanikai/3.1b1pre

bp-42341994-5337-49f6-8fd2-ed2fb2100215
0	thunderbird.exe	nsView::DoResetWidgetBounds	 view/src/nsView.cpp:390
1	thunderbird.exe	nsView::ResetWidgetBounds	view/src/nsView.cpp:331
2	thunderbird.exe	nsViewManager::ProcessPendingUpdates	view/src/nsViewManager.cpp:548
3	thunderbird.exe	nsViewManager::ProcessPendingUpdates	view/src/nsViewManager.cpp:554
4	thunderbird.exe	nsViewManager::FlushPendingInvalidates	view/src/nsViewManager.cpp:2058
5	thunderbird.exe	nsViewManager::EnableRefresh	view/src/nsViewManager.cpp:1780
6	thunderbird.exe	nsViewManager::EndUpdateViewBatch	view/src/nsViewManager.cpp:1823
7	thunderbird.exe	nsIViewManager::UpdateViewBatch::EndUpdateViewBatch	objdir-tb/mozilla/dist/include/nsIViewManager.h:389
8	thunderbird.exe	PresShell::FlushPendingNotifications	layout/base/nsPresShell.cpp:4925
9	thunderbird.exe	PresShell::ReflowEvent::Run	layout/base/nsPresShell.cpp:7080
10	xpcom_core.dll	nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527
11	xpcom_core.dll	NS_ProcessNextEvent_P	objdir-tb/mozilla/xpcom/build/nsThreadUtils.cpp:250 

about half to 1/3 are startup crashes
bp-f1b1a929-0bbd-4311-b22b-e1d582100204 (no extensions)

Comment 1

[Wayne Mery (:wsmwk)]

firefox also has this top of stack, but the couple stacks I looked at arent' matches. The closest is FF 3.6 crash bp-ba9c31da-2d35-457c-8c4c-dfd3c2100214

bp-1bb904f9-23c4-4f6b-9b5b-e078e2100215 is an example that's not a close match.

Comment 2

[Wayne Mery (:wsmwk)]

(assuming current versions have the same crash)
signature is now nsView::DoResetWidgetBounds(bool, bool) 

The following crashes cite the same source line

bp-e0c79c9b-ec16-491a-911a-deb812130420 ff 23.0a1
bp-28abee8a-ef94-4e7c-bb7d-ecb4f2130421 ff 20.0.1
bp-ee7a4ec1-1d89-4ca6-b15c-7c30d2130207 tb17.0.2
bp-4257b25e-5a4e-44cc-9b46-95efc2130421 tb17.0.5
0	XUL	nsView::DoResetWidgetBounds	view/src/nsView.cpp:246
1	XUL	nsViewManager::ProcessPendingUpdatesForView	view/src/nsViewManager.cpp:395
2	XUL	mozilla::image::RasterImage::RequestRefresh	
3	XUL	nsViewManager::ProcessPendingUpdatesForView	view/src/nsViewManager.cpp:401
4	XUL	nsRefreshDriver::ImageRequestEnumerator	
5	XUL	PL_DHashTableEnumerate	objdir-tb/x86_64/mozilla/xpcom/build/pldhash.cpp:715 
hg@1 239 // The geometry of a root view's widget is controlled externally,
hg@1 240 // NOT by sizing or positioning the view
ms2ger@64435
241 if (mViewManager->GetRootViewImpl() == this) {
hg@1 242 return;
hg@1 243 }
hg@1 244
reg@23738 245 nsIntRect curBounds;
justin@82759 246 mWindow->GetClientBounds(curBounds);

Comment 3

[Mats Palmgren (inactive)]

What if the ProcessPendingUpdatesForView call on line 364 destroys the frame tree,
including the frame that owns 'childView', that can happen right?
http://hg.mozilla.org/mozilla-central/annotate/64d6d002e888/view/src/nsViewManager.cpp#l347

Comment 4

[Mats Palmgren (inactive)]

I wonder if we could do the view hierarchy traversal up front, collecting
nsWeakFrames into an array for all views that has a widget.  Then when
processing that array ignore frames that aren't alive or doesn't have
a view or a widget.

Comment 5

[Timothy Nikkel (:tnikkel)]

(In reply to Mats Palmgren [:mats] from comment #3)
> What if the ProcessPendingUpdatesForView call on line 364 destroys the frame
> tree,
> including the frame that owns 'childView', that can happen right?
> http://hg.mozilla.org/mozilla-central/annotate/64d6d002e888/view/src/
> nsViewManager.cpp#l347

Yeah, I think you are right.

We used to have weak views, but we removed the last use of them so we removed them. Not sure if we want to bring them back though.

Comment 6

[Mats Palmgren (inactive)]

ProcessPendingUpdatesForView looks like a NOP for views that doesn't have
a widget though (except for the traversal), and *child* views that has
a widget always has a frame (I think) so we could use nsWeakFrame on those.
I kind of doubt the root view can be destroyed through this path, but if we're
paranoid we could just get it from the vm to check it's alive (we have a strong
ref on the vm here).

Comment 7

[Wayne Mery (:wsmwk)]

From Thunderbird POV this appears to be gone. The one crash I found in 3 months range doesn't have the same stack