322704 - Crash [@ nsTraceRefcntImpl::LogReleaseCOMPtr] with evil testcase, using moz-popup, moz-deck, moz-grid-group

Status: RESOLVED WORKSFORME

(Core :: Widget: Win32, defect)

Description

[Martijn Wargers (dead)]

See  upcoming testcase.
It can crash on load, but otherwise you have to quickly reload to get the crash.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Martijn Wargers (dead)]

Attachment: backtrace

Backtrace from debug build from assertion prior to the crash:
###!!! ASSERTION: Bogus state: '!mLastChild->GetNextSibling()', file c:/mozilla/
mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 294
Break: at file c:/mozilla/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 29
4

And from the crash itself:
#0  0x6ff45798 in nsTraceRefcntImpl::LogReleaseCOMPtr(void*, nsISupports*) (
    this=0x3f6650, aCOMPtr=0xe324870, aObject=0xfeeefeee)
    at c:/mozilla/mozilla/xpcom/base/nsTraceRefcntImpl.cpp:1229
#1  0x6fec49c2 in nsTraceRefcnt::LogReleaseCOMPtr(void*, nsISupports*) (
    aPtr=0xe324870, aObject=0xfeeefeee)
    at c:/mozilla/mozilla/xpcom/build/nsTraceRefcnt.cpp:123
#2  0x6309bb8e in nsCOMPtr<nsIWidget>::assign_assuming_AddRef(nsIWidget*) (
    this=0xe324870, newPtr=0xe32405c)
    at ../../../dist/include/xpcom/nsCOMPtr.h:566
#3  0x6309ba37 in nsCOMPtr<nsIWidget>::assign_with_AddRef(nsISupports*) (
    this=0xe324870, rawPtr=0xe32405c)
    at ../../../dist/include/xpcom/nsCOMPtr.h:1224
#4  0x6309bcdc in nsCOMPtr<nsIWidget>::operator=(nsIWidget*) (this=0xe324870,
    rhs=0xe32405c) at ../../../dist/include/xpcom/nsCOMPtr.h:713
#5  0x6309c10b in nsIWidget::SetNextSibling(nsIWidget*) (this=0xe324864,
    aSibling=0xe32405c) at ../../../dist/include/widget/nsIWidget.h:401
#6  0x63079386 in nsBaseWidget::AddChild(nsIWidget*) (this=0x1029be34,
    aChild=0xe32405c)
    at c:/mozilla/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp:295
etc...

Comment 3

[Mats Palmgren (inactive)]

WFM, 2006-01-06-02 trunk Linux (and no assertions in a debug build).

-> Widget/Win32 for triage

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yeah, the problem seems to be the bad widget state....

Comment 5

[Bob Clary [:bc] (inactive)]

Attachment: www.earthlink.net

source with base href for www.earthlink.net
crash with today's trunk on winxp with jesse's randomstyles parms: seed=172,234,214,244

found when testing bug 316636.

uses deleted memory. You may need to load the test file more than once. 

WARNING: NS_ENSURE_TRUE(mSaveLayoutState || !aState) failed, file c:/work/mozilla/builds/ff/trunk/mozilla/docshell/shistory/src/nsSHEntry.cpp, line 298
###!!! ASSERTION: Bogus state: '!mLastChild->GetNextSibling()', file c:/work/mozilla/builds/ff/trunk/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 294

+	newPtr	0x03a0ee6c
+	oldPtr	0xdddddddd
+	this	0x034fb0f8

nsCOMPtr<nsIWidget>::assign_assuming_AddRef(nsIWidget * 0x03a0ee6c) line 568 + 3 bytes
nsCOMPtr<nsIWidget>::assign_with_AddRef(nsISupports * 0x03a0ee6c) line 1225
nsCOMPtr<nsIWidget>::operator=(nsIWidget * 0x03a0ee6c) line 714
nsIWidget::SetNextSibling(nsIWidget * 0x03a0ee6c) line 402
nsBaseWidget::AddChild(nsIWidget * 0x03a0ee6c) line 296
nsBaseWidget::BaseCreate(nsIWidget * 0x036cd634, const nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x022cfd20 HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x034fbaa8, nsIAppShell * 0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x0012ea24) line 198
nsWindow::StandardWindowCreate(nsIWidget * 0x036cd634, const nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x022cfd20 HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x034fbaa8, nsIAppShell * 0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x0012ea24, void * 0x00000000) line 1420
nsWindow::Create(nsWindow * const 0x03a0ee6c, nsIWidget * 0x036cd634, const nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x022cfd20 HandleEvent(nsGUIEvent *), nsIDeviceContext * 0x034fbaa8, nsIAppShell * 0x00000000, nsIToolkit * 0x00000000, nsWidgetInitData * 0x0012ea24) line 1597
nsIView::CreateWidget(const nsID & {...}, nsWidgetInitData * 0x0012ea24, void * 0x00000000, int 0x00000001, int 0x00000001, nsContentType eContentTypeContentFrame) line 706
nsSubDocumentFrame::CreateViewAndWidget(nsContentType eContentTypeContentFrame) line 751
nsSubDocumentFrame::ShowDocShell() line 687 + 15 bytes
nsSubDocumentFrame::Init(nsSubDocumentFrame * const 0x0393eb6c, nsPresContext * 0x036a1ac0, nsIContent * 0x035220e8, nsIFrame * 0x036cc7e8, nsStyleContext * 0x0386cadc, nsIFrame * 0x00000000) line 277 + 8 bytes
nsCSSFrameConstructor::InitAndRestoreFrame(const nsFrameConstructorState & {...}, nsIContent * 0x035220e8, nsIFrame * 0x036cc7e8, nsStyleContext * 0x0386cadc, nsIFrame * 0x00000000, nsIFrame * 0x0393eb6c, int 0x00000001) line 7047 + 34 bytes
nsCSSFrameConstructor::ConstructHTMLFrame(nsFrameConstructorState & {...}, nsIContent * 0x035220e8, nsIFrame * 0x039acdcc, nsIAtom * 0x003ff0d0, int 0x00000000, nsStyleContext * 0x0386cadc, nsFrameItems & {...}, int 0x00000000) line 5744 + 35 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsFrameConstructorState & {...}, nsIContent * 0x035220e8, nsIFrame * 0x039acdcc, nsIAtom * 0x003ff0d0, int 0x00000000, nsStyleContext * 0x0386cadc, nsFrameItems & {...}, int 0x00000000) line 7944 + 48 bytes
nsCSSFrameConstructor::ConstructFrame(nsFrameConstructorState & {...}, nsIContent * 0x035220e8, nsIFrame * 0x039acdcc, nsFrameItems & {...}) line 7838 + 53 bytes
nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState & {...}, nsIContent * 0x036b7798, nsIFrame * 0x039acdcc, int 0x00000000, nsFrameItems & {...}, int 0x00000000, nsTableCreator * 0x00000000) line 11651 + 58 bytes
nsCSSFrameConstructor::ConstructXULFrame(nsFrameConstructorState & {...}, nsIContent * 0x036b7798, nsIFrame * 0x036cc7e8, nsIAtom * 0x003fefc0, int 0x00000000, nsStyleContext * 0x036cc73c, nsFrameItems & {...}, int 0x00000000, int 0x00000000, int * 0x0012f1b4) line 6506 + 39 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsFrameConstructorState & {...}, nsIContent * 0x036b7798, nsIFrame * 0x036cc7e8, nsIAtom * 0x003fefc0, int 0x00000000, nsStyleContext * 0x036cc73c, nsFrameItems & {...}, int 0x00000000) line 7955 + 56 bytes
nsCSSFrameConstructor::ConstructFrame(nsFrameConstructorState & {...}, nsIContent * 0x036b7798, nsIFrame * 0x036cc7e8, nsFrameItems & {...}) line 7838 + 53 bytes
nsCSSFrameConstructor::ContentInserted(nsIContent * 0x0368b498, nsIContent * 0x036b7798, int 0x00000001, nsILayoutHistoryState * 0x036cd880, int 0x00000000) line 9462
nsCSSFrameConstructor::RecreateFramesForContent(nsIContent * 0x036b7798) line 11531 + 39 bytes
nsCSSFrameConstructor::RestyleElement(nsIContent * 0x036b7798, nsIFrame * 0x036cc96c, nsChangeHint 0x00000000) line 10450
nsCSSFrameConstructor::ProcessOneRestyle(nsIContent * 0x036b7798, nsReStyleHint eReStyle_Self, nsChangeHint 0x00000000) line 13250
nsCSSFrameConstructor::ProcessPendingRestyles() line 13303
nsCSSFrameConstructor::RestyleEvent::HandleEvent() line 13369
HandleRestyleEvent(PLEvent * 0x0342c3f8) line 13378

Comment 6

[Bob Clary [:bc] (inactive)]

loading earthlink source from bugzilla gives the same crash but with 

+	newPtr	0x0421d544
-	oldPtr	0x036c4728
+	nsISupports	{...}
+	mFirstChild	{...}
+	mLastChild	0xfdfdfdfd
+	mNextSibling	{...}
+	mPrevSibling	0x00070007
-	this	0x042342e0
+	mRawPtr	0x0421d544

0xfd is a boundary marker in ms debug builds
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__malloc_dbg.asp>

<quote>
_malloc_dbg allocates the memory block with slightly more space than the requested size. The additional space is used by the debug heap manager to link the debug memory blocks together and to provide the application with debug header information and overwrite buffers. When the block is allocated, the user portion of the block is filled with the value 0xCD and each of the overwrite buffers are filled with 0xFD.
</quote>

so this is also a potential heap overrun?

Comment 7

[Jesse Ruderman]

Sicking can reproduce with the testcase in comment 1 with a recent trunk build.  He's going to try to fix.

Comment 8

[Jesse Ruderman]

I think this causes some of the pain in bug 336899, including a half-hang state and "ASSERTION: reflowing in the middle of frame construction".  Stack traces and partially reduced testcase in that bug.

Sicking, have you tried to fix this?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sorry, it's not been on my radar. I'll try to get to it soon.

Comment 10

[Jesse Ruderman]

Roc, can you look at this bug?  Sicking is overburdened, and you know widgets.

Comment 11

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

If this is really Windows-only, then I won't be able to fix it. I'm on Linux.

Comment 12

[Bob Clary [:bc] (inactive)]

ff2 nightly 20060825 linux crash
ff2 debug   20060825 linux crash
ff2 nightly 20060825 winxp crash autorestarts
ff2 debug   20060825 winxp crash debugger can't load symbols, auto restarts browser

looks like the stack is really horked.

Comment 13

[Jesse Ruderman]

roc, can you reproduce this bug in a GTK2 build?

Comment 14

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

Sorry, I don't crash on my fresh GTK2-cairo-trunk-debug build. No assertions either.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

I wasn't able to get that testcase to crash with a windows trunk build from today. Martijn, can you retest?

Comment 16

[Martijn Wargers (dead)]

Ok, this is indeed worksforme now, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061114 Minefield/3.0a1
I also tried to crash with the www.earthlink.net testcase, using the randomstyles bookmarklet, that one is also wfm.