Closed Bug 345659 Opened 19 years ago Closed 19 years ago

crash on quit in layout [@ nsFrameManager::CaptureFrameStateFor], aFrame has been deleted/freed

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 336662

People

(Reporter: moco, Unassigned)

Details

(Keywords: crash, regression, Whiteboard: [exposed by "all tabs" menupopup?])

Crash Data

crash on quit in nsFrameManager::CaptureFrameStateFor(), frame has been deleted this is with my own, debug trunk build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060723 Minefield/3.0a1 From nsFrameManager::CaptureFrameStateFor(), - aFrame 0x0432b2dc {mRect={...} mContent=0xdddddddd mStyleContext=0xdddddddd ...} nsIFrame * + nsISupports {...} nsISupports + mRect {x=-572662307 y=-572662307 width=-572662307 ...} nsRect + mContent 0xdddddddd nsIContent * + mStyleContext 0xdddddddd {mParent=??? mChild=??? mEmptyChild=??? ...} nsStyleContext * + mParent 0xdddddddd {mRect={...} mContent=??? mStyleContext=??? ...} nsIFrame * + mNextSibling 0xdddddddd {mRect={...} mContent=??? mStyleContext=??? ...} nsIFrame * mState 3722304989 unsigned int The crash is actually in CallQueryInterface(). Here's the stack: gklayout.dll!CallQueryInterface<nsIFrame,nsIStatefulFrame>(nsIFrame * aSource=0x0432b2dc, nsIStatefulFrame * * aDestination=0x0012e844) Line 223 + 0x13 bytes C++ gklayout.dll!nsFrameManager::CaptureFrameStateFor(nsIFrame * aFrame=0x0432b2dc, nsILayoutHistoryState * aState=0x04013688, nsIStatefulFrame::SpecialStateID aID=eNoID) Line 1428 + 0xd bytes C++ > gklayout.dll!nsFrameManager::CaptureFrameState(nsIFrame * aFrame=0x0432b2dc, nsILayoutHistoryState * aState=0x04013688) Line 1468 C++ gklayout.dll!nsCSSFrameConstructor::CaptureStateFor(nsIFrame * aFrame=0x0432b2dc, nsILayoutHistoryState * aHistoryState=0x04013688) Line 11571 C++ gklayout.dll!nsCSSFrameConstructor::RemoveMappingsForFrameSubtree(nsIFrame * aRemovedFrame=0x0432b2dc) Line 9865 C++ gklayout.dll!nsMenuFrame::DestroyPopupFrames(nsPresContext * aPresContext=0x00c440e8) Line 321 C++ gklayout.dll!nsMenuFrame::Destroy() Line 354 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!nsBoxFrame::Destroy() Line 1093 C++ gklayout.dll!nsFrameList::DestroyFrames() Line 61 C++ gklayout.dll!nsContainerFrame::Destroy() Line 160 C++ gklayout.dll!ViewportFrame::Destroy() Line 66 C++ gklayout.dll!nsFrameManager::Destroy() Line 293 C++ gklayout.dll!PresShell::Destroy() Line 1961 C++ gklayout.dll!DocumentViewerImpl::Destroy() Line 1612 C++ docshell.dll!nsDocShell::Destroy() Line 3622 C++ appshell.dll!nsXULWindow::Destroy() Line 507 C++ appshell.dll!nsWebShellWindow::Destroy() Line 828 + 0x9 bytes C++ appshell.dll!nsWebShellWindow::HandleEvent(nsGUIEvent * aEvent=0x0012ee94) Line 387 C++ gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012ee94, nsEventStatus & aStatus=nsEventStatus_eIgnore) Line 1102 + 0xc bytes C++ gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * event=0x0012ee94) Line 1123 C++ gkwidget.dll!nsWindow::DispatchStandardEvent(unsigned int aMsg=101) Line 1142 + 0x11 bytes C++ gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=16, unsigned int wParam=0, long lParam=0, long * aRetValue=0x0012f2c8) Line 4270 C++ gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x001403b2, unsigned int msg=16, unsigned int wParam=0, long lParam=0) Line 1291 + 0x1d bytes C++ user32.dll!77d48734() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!77d48816() user32.dll!77d4b4c0() user32.dll!77d4b50c() ntdll.dll!7c90eae3() user32.dll!77d494be() user32.dll!77d4b42d() user32.dll!77d4baa4() user32.dll!77d4b96b() user32.dll!77d4b3f9() uxtheme.dll!5ad73c20() uxtheme.dll!5ad8e300() uxtheme.dll!5ad71ac7() uxtheme.dll!5ad71b3d() uxtheme.dll!5ad8e2d5() user32.dll!77d4bb15() nspr4.dll!_MD_CURRENT_THREAD() Line 296 + 0xc bytes C gkwidget.dll!nsWindow::DefaultWindowProc(HWND__ * hWnd=0x001403b2, unsigned int msg=274, unsigned int wParam=61536, long lParam=263410) Line 1312 C++ user32.dll!77d48734() user32.dll!77d48816() user32.dll!77d4c63f() user32.dll!77d4c665() gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x039b8d24, unsigned int msg=1242936, unsigned int wParam=38158168, long lParam=0) Line 1298 + 0x1f bytes C++ nspr4.dll!PR_GetCurrentThread() Line 175 C gkwidget.dll!nsWindow::`vftable'() + 0x23 bytes C++ gkwidget.dll!02409c1f() 4d890cec()
Seth, is this reproducible?
> Seth, is this reproducible? not 100% of the time. FWIW, it just happened to me again. I've see this crash on quit about 5 times now in the past 2 or 3 days, if that helps.
Severity: normal → critical
Keywords: crash
Is there anything in particular that I could do to make this more likely to reproduce? Just starting, browsing for a few mins, and quitting doesn't seem to crash...
> Is there anything in particular that I could do to make this more likely to > reproduce? Just starting, browsing for a few mins, and quitting doesn't seem > to crash... I haven't figure out the trick yet. My uneducated guess is that it might be related to quitting when I've got multiple windows and multiple tabs per window.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Summary: crash on quit in layout nsFrameManager::CaptureFrameStateFor(), aFrame has been deleted/freed → crash on quit in layout [@ nsFrameManager::CaptureFrameStateFor], aFrame has been deleted/freed
I can reproduce it very often (but not every time) when I start Firefox in a new profile, load the folder "quick searches" in tabs, and open and close the new tab menu a few times. After that I get a crash on close. Sometimes the amount of tabs doubles after the crash. As I can't reproduce it consistently, I can't figure out when it regressed.
I get also a crash in 1.9a1_2006072312. Maybe caused by bug 195212?
I can reproduce this on trunk builds: - Open the new tab bar menu - Click on the outside edge of the popup without have selected any menu-item - Close the popup menu (doesn't matter how) - Close the window Result: crash I can't reproduce this with current 1.8.1 branch builds.
I see it also in 1.9a1_2006072306. The next one, 1.9a1_2006072222, crashes only sometimes on startup until now (TB21393535W).
So is this similar to bug 288763? Sure sounds like it...
Depends on: 288763
martijn, thanks for coming up with a test case! I don't think I've seen this on the branch either, but I'll keep an eye out for it.
Whiteboard: [exposed by "all tabs" menupopup?]
Backing out bug 345260 fixed this for me.
(In reply to comment #12) > Weird, because the crash was already present before this patch was checked in. It crashes here on exit after hovering over the button until the tooltip appears.
hrm, maybe not, i can no longer reproduce this here w/ or w/o this patch. :-/
Also on branch now.
So this has to be bug 345260 :-/
(Assuming you were testing a hourly build after its branch landing).
OK, now that i can always reproduce it, it looks like you were right - backing out bug 345257 prevents the crash.
Blocks: 345257
Keywords: regression
backed out bug 345257. *** This bug has been marked as a duplicate of 336662 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
No longer depends on: 288763
No longer blocks: 345257
Crash Signature: [@ nsFrameManager::CaptureFrameStateFor]
You need to log in before you can comment on or make changes to this bug.