421710 - Crash on print preview or print on www.spiegel.de

Status: VERIFIED FIXED

(Core :: Layout, defect, P2)

Description

[Robert [minotaur 11]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030804 Minefield/3.0b5pre

On Windows XP the crash doesn't always happen instantly.

Reproducible: Always

Steps to Reproduce:
1.Load http://www.spiegel.de/
2.Open File -> Print Preview or try to print the page
Actual Results:  
Firefox crashes


Crash reports:
Ubuntu 7.10
http://crash-stats.mozilla.com/report/index/7968b7d7-ed26-11dc-b60d-001a4bd46e84
http://crash-stats.mozilla.com/report/index/94c50ef0-ed26-11dc-a688-001a4bd43ef6
Windows XP
http://crash-stats.mozilla.com/report/index/c3107e99-ed30-11dc-9da7-001a4bd46e84

http://crash-stats.mozilla.com/report/index/ee27ccb3-ed30-11dc-9b1a-001a4bd43ef6

Regression range (linux builds):
2007113016 works
2007120104 fails

Bonsai query:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-11-30+16%3A00%3A00&maxdate=2007-12-01+04%3A59%3A59

Maybe bug 395628?

Comment 1

[Robert [minotaur 11]]

The second crash report for ubuntu is useless, should have been:
http://crash-stats.mozilla.com/report/index/597a8c8a-ed26-11dc-be8d-001a4bd46e84

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

confirming: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre)
Gecko/2008030806 Firefox/3.0.0.0 ID:2008030806

http://crash-stats.mozilla.com/report/index/3e244338-ed38-11dc-8aea-001a4bd43e5c
http://crash-stats.mozilla.com/report/index/d3739f68-ed38-11dc-be59-001a4bd46e84

Comment 3

[Mats Palmgren (inactive)]

###!!! ASSERTION: bad prev-in-flow ancestor chain: 'nsLayoutUtils::IsProperAncestorFrame(prevBlock, fpif)', nsBlockFrame.cpp, line 4454
WARNING: nsBlockFrame::CheckFloats: Explicit float list is out of sync with float cache: nsBlockFrame.cpp, line 6725
###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed: 'mFrameCount == 0', nsPresShell.cpp, line 677

Comment 4

[Mats Palmgren (inactive)]

Backing out bug 405178: still crash and AllocateFrame assert
Backing out bug 405178 and 400244: no crash, no AllocateFrame assert
Backing out bug 400244: no crash, no AllocateFrame assert
all three combinations triggers the CheckFloats warning though

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #3)
> ###!!! ASSERTION: Some objects allocated with AllocateFrame were not freed:
> 'mFrameCount == 0', nsPresShell.cpp, line 677

For what it's worth:  it was 14323 objects leaked; significant chunks of frame tree, including style contexts and style data, at first glance.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Can someone attach a reproducible testcase (doesn't have to be minimal) to this bug in case the site changes?

Comment 7

[Michal Novotny [:michal]]

Attachment: testcase (tarball)

obtained with wget -E -H -k -K -p ...
use testcase2/www.spiegel.de/politik/ausland/0,1518,541876,00.html

Comment 8

[Michal Novotny [:michal]]

Attachment: slightly reduced testcase (tarball)

The same as #310021, but few files removed and html reduced.

Comment 9

[Michal Novotny [:michal]]

I'm tracking down the bug, but I really need help from someone who understand layout code. The problem is that one nsHTMLScrollFrame that is created during reflowing in nsPrintEngine::SetupToPrintContent() isn't destroyed correctly when whole document is destroyed. Posted overflow event for that nsHTMLScrollFrame(i.e. nsGfxScrollFrameInner) is handled after document is destroyed and memory of that frame is no longer valid.

Here are the steps to see problematic frames:

1) in FF load page testcase2/www.spiegel.de/politik/ausland/0,1518,541876,00.html from https://bugzilla.mozilla.org/attachment.cgi?id=310022

2) attach with gdb to the process, set break on nsPrintEngine::SetupToPrintContent and continue

(gdb) b nsPrintEngine::SetupToPrintContent()
Breakpoint 1 at 0x17ed267: file /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintEngine.cpp, line 1588.
Current language:  auto; currently asm
(gdb) c


3) do File->Print Preview in FF
delete old breakpoint and set new on nsGfxScrollFrameInner constructor (the third created frame is the right one)

Breakpoint 1, nsPrintEngine::SetupToPrintContent (this=0xae21b80)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintEngine.cpp:1588
1588      if (NS_FAILED(EnablePOsForPrinting())) {
Current language:  auto; currently c++
(gdb) dele
Delete all breakpoints? (y or n) y
(gdb) b 'nsGfxScrollFrameInner::nsGfxScrollFrameInner(nsContainerFrame*, int, int)'
Breakpoint 2 at 0x12b676c: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp, line 1271.
Breakpoint 3 at 0x12b654c: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp, line 1271.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) ignore 3 2
Will ignore next 2 crossings of breakpoint 3.
(gdb) c
Continuing.

Breakpoint 3, nsGfxScrollFrameInner::nsGfxScrollFrameInner (this=0xb409390, aOuter=0xb409344, aIsRoot=0, aIsXUL=0)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:1271
1271        mMayHaveDirtyFixedChildren(PR_FALSE)
(gdb) fin
Run till exit from #0  nsGfxScrollFrameInner::nsGfxScrollFrameInner (this=0xb409390, aOuter=0xb409344, aIsRoot=0, aIsXUL=0)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:1271
nsHTMLScrollFrame::nsHTMLScrollFrame (this=0xb409344, aShell=0xb398400, aContext=0xb409240, aIsRoot=0)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:97
97      }
(gdb) dele
Delete all breakpoints? (y or n) y


4) Posted event of this nsGfxScrollFrameInner will cause the crash in future. I'll follow the nsHTMLScrollFrame frame that has it as mInner member. During the reflow it will be 2x reparented due to call to DrainOverflowLines(), let's trace it.

(gdb) p &mParent
$1 = (nsIFrame **) 0xb409360
(gdb) watch *0xb409360
Hardware watchpoint 4: *188781408
(gdb) c 
Continuing. 
Hardware watchpoint 4: *162480172 

Old value = 0 
New value = 162406520 
nsFrame::Init (this=0x9af4010, aContent=0x97ff1a0, aParent=0x9ae2078, aPrevInFlow=0x0) 
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsFrame.cpp:406 
406       if (aContent) {
(gdb)  c 
Continuing. 
Hardware watchpoint 4: *162480172 
 
Old value = 162406520 
New value = 163102440 
0x012a5976 in nsIFrame::SetParent (this=0x9af4010, aParent=0x9b8bee8) 
    at /opt/moz/TRUNK_new3/mozilla/layout/xul/base/src/../../../generic/nsIFrame.h:690 
690       NS_IMETHOD SetParent(const nsIFrame* aParent) { mParent = (nsIFrame*)aParent; return NS_OK; } 


5) These were initial setting of parent and first ReparentFrame(). Second ReparentFrame() (and last in my case) will set parent to nsAreaFrame that will be created just now. so set the breakpoint to constructor.

(gdb) b 'nsAreaFrame::nsAreaFrame(nsStyleContext*)' 
Breakpoint 5 at 0x133073e: file /opt/moz/TRUNK_new3/mozilla/layout/forms/../generic/nsAreaFrame.h, line 87. 
Breakpoint 6 at 0x126bad6: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.h, line 87. 
warning: Multiple breakpoints were set. 
Use the "delete" command to delete unwanted breakpoints. 
(gdb) c 
Continuing. 
 
Breakpoint 6, nsAreaFrame::nsAreaFrame (this=0xb2c4918, aContext=0xb3f5370) 
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.h:87 
87        nsAreaFrame(nsStyleContext *aContext) : nsBlockFrame(aContext) {} 
(gdb) dele 5 6 


6)  When returning to frame 3 I can see also placeholderFrame for this (nsAreaFrame *)0xb2c4918

(gdb) f 2
#2  0x011e3982 in nsCSSFrameConstructor::CreateContinuingFrame (this=0xa3ba580, aPresContext=0xad12ad0, aFrame=0xb274ea4, 
    aParentFrame=0xb274f5c, aContinuingFrame=0xbfce5a54, aIsFluid=1)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp:10496
10496       newFrame = NS_NewAreaFrame(shell, styleContext, 0);
(gdb) fin
Run till exit from #2  0x011e3982 in nsCSSFrameConstructor::CreateContinuingFrame (this=0xa3ba580, aPresContext=0xad12ad0, 
    aFrame=0xb274ea4, aParentFrame=0xb274f5c, aContinuingFrame=0xbfce5a54, aIsFluid=1)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp:10496
0x011e40c8 in nsCSSFrameConstructor::CreateContinuingFrame (this=0xa3ba580, aPresContext=0xad12ad0, aFrame=0xb274efc, 
    aParentFrame=0xb274f5c, aContinuingFrame=0xbfce5ad4, aIsFluid=1)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp:10636
10636       rv = CreateContinuingFrame(aPresContext, oofFrame, aParentFrame, &oofContFrame);
(gdb) n
10637       if (NS_FAILED(rv)) {
(gdb) n
10643                                      aParentFrame, aFrame, &newFrame);
(gdb) n
10644       if (NS_FAILED(rv)) {
(gdb) p newFrame 
$3 = (class nsIFrame *) 0xb2c4970 
(gdb) p *(nsPlaceholderFrame *)newFrame 
$4 = {<nsSplittableFrame> = {<nsFrame> = {<nsBox> = {<nsIFrame> = {<nsISupports> = {_vptr.nsISupports = 0x2349b28}, mRect = { 
            x = 0, y = 0, width = 0, height = 0}, mContent = 0xafa9660, mStyleContext = 0xb3efdac, mParent = 0xb274f5c,  
          mNextSibling = 0x0, mState = 1030}, static gGotTheme = 1,  
        static gTheme = 0xa537800}, <nsIFrameDebug> = {<nsISupports> = { 
          _vptr.nsISupports = 0x2349d78}, <No data fields>}, <No data fields>}, mPrevContinuation = 0xb274efc,  
    mNextContinuation = 0x0}, mOutOfFlowFrame = 0xb2c4918} 


7) Find out parent of (nsAreaFrame *)0xb2c4918 and make sure that it will not change the parent.

(gdb) p ((nsAreaFrame *)0xb2c4918).mParent
$5 = (nsIFrame *) 0xb274f5c
(gdb) x/wa*(void**) 0xb274f5c
0x2344948 <_ZTV12nsBlockFrame+8>:       0x1280bc8 <_ZN12nsBlockFrame14QueryInterfaceERK4nsIDPPv>
(gdb) p &((nsAreaFrame *)0xb2c4918).mParent
$6 = (nsIFrame **) 0xb2c4934
(gdb) watch *0xb2c4934
Hardware watchpoint 7: *187451700


8) Now wait for final parent change on (nsHTMLScrollFrame *)0xb409344

(gdb) c 
Continuing. 
Hardware watchpoint 4: *188781408 
 
Old value = 187125412 
New value = 187451672 
0x012a5976 in nsIFrame::SetParent (this=0xb409344, aParent=0xb2c4918) 
    at /opt/moz/TRUNK_new3/mozilla/layout/xul/base/src/../../../generic/nsIFrame.h:690 
690       NS_IMETHOD SetParent(const nsIFrame* aParent) { mParent = (nsIFrame*)aParent; return NS_OK; } 


This final hierarchy on my PC:

(nsHTMLScrollFrame *)0xb409344 has parent
(nsAreaFrame *)0xb2c4918 that has parent
(nsBlockFrame *)0xb274f5c

I can't find any reference to nsAreaFrame from nsBlockFrame. In mLines I can see only reference to its placeholder (nsPlaceholderFrame *)0xb2c4970. nsAreaFrame::Destroy() isn't called from nsBlockFrame::Destroy(). ((nsPlaceholderFrame *)0xb2c4970).mOutOfFlowFrame is 0 at that time.

(gdb) p ((nsPlaceholderFrame *)0xb2c4970).mOutOfFlowFrame
$7 = (class nsIFrame *) 0xb2c4918
(gdb) p &((nsPlaceholderFrame *)0xb2c4970).mOutOfFlowFrame
$8 = (class nsIFrame **) 0xb2c49a4
(gdb) watch *0xb2c49a4
Hardware watchpoint 8: *187451812
(gdb) b 'nsBlockFrame::Destroy()' if (this == 0xb274f5c)
Breakpoint 9 at 0x1280d7c: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsBlockFrame.cpp, line 288.
(gdb) b 'nsAreaFrame::Destroy()' if (this == 0xb2c4918)
Breakpoint 10 at 0x126b5b4: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.cpp, line 133.
(gdb) b 'nsHTMLScrollFrame::Destroy()' if (this == 0xb409344)
Breakpoint 11 at 0x12bdc48: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp, line 156.
(gdb) b 'nsPlaceholderFrame::Destroy()' if (this == 0xb2c4970)
Breakpoint 12 at 0x12f0bc5: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsPlaceholderFrame.cpp, line 128.
(gdb) c
Continuing.
Hardware watchpoint 8: *187451812

Old value = 187451672
New value = 0
0x011f6bd0 in nsPlaceholderFrame::SetOutOfFlowFrame (this=0xb2c4970, aFrame=0x0)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsPlaceholderFrame.h:97
97        void       SetOutOfFlowFrame(nsIFrame* aFrame) {mOutOfFlowFrame = aFrame;}
(gdb) bt 10
#0  0x011f6bd0 in nsPlaceholderFrame::SetOutOfFlowFrame (this=0xb2c4970, aFrame=0x0)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsPlaceholderFrame.h:97
#1  0x0122f5da in UnregisterPlaceholders (table=0xb398448, hdr=0xb4a9880, number=5, arg=0x0)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsFrameManager.cpp:528
#2  0x01e4fec4 in PL_DHashTableEnumerate (table=0xb398448, 
    etor=0x122f5b8 <UnregisterPlaceholders(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*)>, arg=0x0) at pldhash.c:724
#3  0x01232cae in nsFrameManager::ClearPlaceholderFrameMap (this=0xb39841c)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsFrameManager.cpp:536
#4  0x01232d4e in nsFrameManager::Destroy (this=0xb39841c) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsFrameManager.cpp:280
#5  0x012589c5 in PresShell::Destroy (this=0xb398400) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:1677
#6  0x017f2751 in nsPrintObject::DestroyPresentation (this=0xae21bc0)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintObject.cpp:96
#7  0x017ed49b in nsPrintEngine::SetupToPrintContent (this=0xae21b80)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintEngine.cpp:1637
#8  0x017eda3b in nsPrintEngine::DocumentReadyForPrinting (this=0xae21b80)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintEngine.cpp:1439
#9  0x017ee83e in nsPrintEngine::FinishPrintPreview (this=0xae21b80)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintEngine.cpp:3071
(More stack frames follow...)
(gdb) dele 8 
(gdb) c
Continuing.

Breakpoint 9, nsBlockFrame::Destroy (this=0xb274f5c) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsBlockFrame.cpp:288
288       mAbsoluteContainer.DestroyFrames(this);
(gdb) c
Continuing.

Breakpoint 12, nsPlaceholderFrame::Destroy (this=0xb2c4970)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsPlaceholderFrame.cpp:128
128       nsIPresShell* shell = PresContext()->GetPresShell();
(gdb) bt 10
#0  nsPlaceholderFrame::Destroy (this=0xb2c4970) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsPlaceholderFrame.cpp:128
#1  0x012d8909 in nsLineBox::DeleteLineList (aPresContext=0xad12ad0, aLines=@0xb274f9c)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsLineBox.cpp:340
#2  0x01280e0f in nsBlockFrame::Destroy (this=0xb274f5c) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsBlockFrame.cpp:300
#3  0x012d8909 in nsLineBox::DeleteLineList (aPresContext=0xad12ad0, aLines=@0xb2c4850)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsLineBox.cpp:340
#4  0x01280e0f in nsBlockFrame::Destroy (this=0xb2c4810) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsBlockFrame.cpp:300
#5  0x0126b5d2 in nsAreaFrame::Destroy (this=0xb2c4810) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.cpp:134
#6  0x012ab860 in nsFrameList::DestroyFrames (this=0xb2c48e0) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsFrameList.cpp:67
#7  0x01290463 in nsContainerFrame::Destroy (this=0xb2c48ac)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsContainerFrame.cpp:257
#8  0x01329b5c in ViewportFrame::Destroy (this=0xb2c48ac) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsViewportFrame.cpp:68
#9  0x012ab860 in nsFrameList::DestroyFrames (this=0xb2c489c) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsFrameList.cpp:67
(More stack frames follow...)
(gdb) c
Continuing.
Hardware watchpoint 4: *188781408

Old value = 187451672
New value = -623191334
0x0033a3d7 in memset () from /lib/libc.so.6
(gdb) bt 10
#0  0x0033a3d7 in memset () from /lib/libc.so.6
#1  0x002460c2 in FreeArenaList (pool=0xb3984e4, head=0xb3984e4, reallyFree=1)
    at /opt/moz/TRUNK_new3/mozilla/nsprpub/lib/ds/plarena.c:279
#2  0x0024623e in PL_FinishArenaPool (pool=0xb3984e4) at /opt/moz/TRUNK_new3/mozilla/nsprpub/lib/ds/plarena.c:327
#3  0x01259ff9 in FrameArena::~FrameArena (this=0xb3984e0) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:677
#4  0x0125abe2 in PresShell::~PresShell$delete (this=0xb398400)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:1433
#5  0x01259454 in PresShell::Release (this=0xb398400) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:1404
#6  0x011fa64e in nsCOMPtr<nsIPresShell>::assign_assuming_AddRef (this=0xae21bcc, newPtr=0x0)
    at ../../../dist/include/xpcom/nsCOMPtr.h:568
#7  0x0122a7fe in nsCOMPtr<nsIPresShell>::assign_with_AddRef (this=0xae21bcc, rawPtr=0x0)
    at ../../../../dist/include/xpcom/nsCOMPtr.h:1267
#8  0x0122c834 in nsCOMPtr<nsIPresShell>::operator= (this=0xae21bcc, rhs=0x0) at ../../dist/include/xpcom/nsCOMPtr.h:713
#9  0x017f2767 in nsPrintObject::DestroyPresentation (this=0xae21bc0)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintObject.cpp:98
(More stack frames follow...)
(gdb) dele 4
(gdb) c
Continuing.
Hardware watchpoint 7: *187451700

Old value = 187125596
New value = -623191334
0x0033a3d7 in memset () from /lib/libc.so.6
(gdb) bt 10
#0  0x0033a3d7 in memset () from /lib/libc.so.6
#1  0x002460c2 in FreeArenaList (pool=0xb3984e4, head=0xb3984e4, reallyFree=1)
    at /opt/moz/TRUNK_new3/mozilla/nsprpub/lib/ds/plarena.c:279
#2  0x0024623e in PL_FinishArenaPool (pool=0xb3984e4) at /opt/moz/TRUNK_new3/mozilla/nsprpub/lib/ds/plarena.c:327
#3  0x01259ff9 in FrameArena::~FrameArena (this=0xb3984e0) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:677
#4  0x0125abe2 in PresShell::~PresShell$delete (this=0xb398400)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:1433
#5  0x01259454 in PresShell::Release (this=0xb398400) at /opt/moz/TRUNK_new3/mozilla/layout/base/nsPresShell.cpp:1404
#6  0x011fa64e in nsCOMPtr<nsIPresShell>::assign_assuming_AddRef (this=0xae21bcc, newPtr=0x0)
    at ../../../dist/include/xpcom/nsCOMPtr.h:568
#7  0x0122a7fe in nsCOMPtr<nsIPresShell>::assign_with_AddRef (this=0xae21bcc, rawPtr=0x0)
    at ../../../../dist/include/xpcom/nsCOMPtr.h:1267
#8  0x0122c834 in nsCOMPtr<nsIPresShell>::operator= (this=0xae21bcc, rhs=0x0) at ../../dist/include/xpcom/nsCOMPtr.h:713
#9  0x017f2767 in nsPrintObject::DestroyPresentation (this=0xae21bc0)
    at /opt/moz/TRUNK_new3/mozilla/layout/printing/nsPrintObject.cpp:98
(More stack frames follow...)
(gdb) dele 7
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault. 
0x011f693a in nsRuleNode::GetPresContext (this=0x2404890c) at ../../../dist/include/layout/nsRuleNode.h:702 
702       nsPresContext* GetPresContext() const { return mPresContext; } 
Current language:  auto; currently c++ 
(gdb) bt 5
#0  0x011f693a in nsRuleNode::GetPresContext (this=0x2404890c) at ../../../dist/include/layout/nsRuleNode.h:702
#1  0x011f69d9 in nsIFrame::PresContext (this=0x2352bd0) at ../../../dist/include/layout/nsIFrame.h:471
#2  0x012b9fa3 in nsGfxScrollFrameInner::AsyncScrollPortEvent::Run (this=0xb4a8340)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:1925
#3  0x01ebf655 in nsThread::ProcessNextEvent (this=0xa147e20, mayWait=1, result=0xbfce99f4)
    at /opt/moz/TRUNK_new3/mozilla/xpcom/threads/nsThread.cpp:510
#4  0x01e5b565 in NS_ProcessNextEvent_P (thread=0xa147e20, mayWait=1) at nsThreadUtils.cpp:227
(More stack frames follow...)
(gdb) f 2
#2  0x012b9fa3 in nsGfxScrollFrameInner::AsyncScrollPortEvent::Run (this=0xb4a8340)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:1925
1925          FlushPendingNotifications(Flush_Layout);
(gdb) p mInner
$9 = (nsGfxScrollFrameInner *) 0xb409390


I think that problem is that nsAreaFrame::Destroy() wasn't called.
In (nsBlockFrame*)0xb274f5c should be reference only to (nsPlaceholderFrame*)0xb2c4970 or (nsAreaFrame*)0xb2c4918 or both? And Where it should/can be stored? In mAbsoluteContainer, mLines, mFloats, OutOfFlowFrame, ... ?

Sorry for the dumb questions but I saw this code first time when I started working on this bug...

Comment 10

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

The float child (nsAreaFrame*)0xb2c4918 (at least I assume it's floated) should always be either in mFloats or the list returned by GetOverflowOutOfFlows().

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: slightly reduced testcase (one HTML file)

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2 (doesn't always crash)

Comment 13

[Michal Novotny [:michal]]

It doesn't crash with http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/07/2007-07-06-05-trunk/
and crashes with http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/07/2007-07-06-14-trunk/ and newer.

Comment 14

[Daniel Holbert [:dholbert]]

I see that same regression range with attachment 310022 [details] (the tarball), though not with the newer testcases.

Perhaps the time needed for image loading and JS execution help the bug to reproduce.  (I removed images / JS files from the newer testcases)

Bonsai link for this regression range:
http://tinyurl.com/2usmkp

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to comment #14)
> I see that same regression range with attachment 310022 [details] (the tarball), though
> not with the newer testcases.
> 
> Perhaps the time needed for image loading and JS execution help the bug to
> reproduce.  (I removed images / JS files from the newer testcases)
> 
> Bonsai link for this regression range:
> http://tinyurl.com/2usmkp

No obvious culprits jump out at me... Maybe bug 386900, as that deals with float placement.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to comment #15)
> No obvious culprits jump out at me... Maybe bug 386900, as that deals with
> float placement.

Yup -- I just checked out a build from around 2007-07-06-14, and it crashes, but if I back out bug 386900's patch, it's fixed.

Marking dependency.

Comment 17

[Michal Novotny [:michal]]

Attachment: reverse patch for 270995 against current TRUNK

Comment 18

[Michal Novotny [:michal]]

Although backing out 270995 suppress the crash I don't think that the patch introduced the problem. It just influence how the document is built. There is problem with one (the second) nsAreaFrame created on line nsCSSFrameConstructor.cpp:10636

(gdb) b nsCSSFrameConstructor.cpp:10637
Breakpoint 1 at 0x11e40cb: file /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10637.
(gdb) c
Continuing.

Breakpoint 1, nsCSSFrameConstructor::CreateContinuingFrame (this=0xa0ee880, aPresContext=0x9c19e30, aFrame=0xa4b40d0, 
    aParentFrame=0xa4b2988, aContinuingFrame=0xbfabe8b4, aIsFluid=1)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp:10637
10637       if (NS_FAILED(rv)) {
(gdb) p oofContFrame 
$1 = (class nsIFrame *) 0xa4f1ee8
(gdb) b 'nsAreaFrame::Destroy()' if (this == 0xa4f1ee8)
Breakpoint 2 at 0x126b5b4: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.cpp, line 133.
(gdb) c
Continuing.

Breakpoint 1, nsCSSFrameConstructor::CreateContinuingFrame (this=0xa0ee880, aPresContext=0x9c19e30, aFrame=0xa4f1f40, 
    aParentFrame=0xa4f1fa0, aContinuingFrame=0xbfabe8c4, aIsFluid=1)
    at /opt/moz/TRUNK_new3/mozilla/layout/base/nsCSSFrameConstructor.cpp:10637
10637       if (NS_FAILED(rv)) {
(gdb) p oofContFrame 
$2 = (class nsIFrame *) 0xa2b4940
(gdb) b 'nsAreaFrame::Destroy()' if (this == 0xa2b4940)
Note: breakpoint 2 also set at pc 0x126b5b4.
Breakpoint 3 at 0x126b5b4: file /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.cpp, line 133.
(gdb) c
Continuing.

Breakpoint 2, nsAreaFrame::Destroy (this=0xa4f1ee8) at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsAreaFrame.cpp:133
133       RegUnregAccessKey(PR_FALSE);
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x012b9fad in nsGfxScrollFrameInner::AsyncScrollPortEvent::Run (this=0xa4aed30)
    at /opt/moz/TRUNK_new3/mozilla/layout/generic/nsGfxScrollFrame.cpp:1925
1925          FlushPendingNotifications(Flush_Layout);


There is no call to nsAreaFrame::Destroy() for the second nsAreaFrame. I was playing with values returned from nsBlockReflowState::CanPlaceFloat() and if I alter return value from 0 to 1 of the 105th call to nsBlockReflowState::CanPlaceFloat() firefox doesn't crash. The second nsAreaFrame isn't created so it doesn'r crash in this particular case but doesn't solve the bug generally.

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Attachment: hack using weakframes

This may or may not help when debugging. Fixes the crash, but shouldn't be needed.

Comment 20

[Michal Novotny [:michal]]

Attachment: fixes crash

Problem seems to be in creating continuation frame for placeholder on line http://mxr.mozilla.org/firefox/source/layout/generic/nsBlockFrame.cpp#3649
Continuation placeholder is stored into mLines in SplitLine() called from http://mxr.mozilla.org/firefox/source/layout/generic/nsBlockFrame.cpp#3658 but the real frame isn't stored anywhere.

I changed it analogously to http://mxr.mozilla.org/firefox/source/layout/generic/nsBlockFrame.cpp#3687
SplitPlaceholder() stores continuation placeholder into aState.mOverflowPlaceholders and real frame is handled later on http://mxr.mozilla.org/firefox/source/layout/generic/nsBlockFrame.cpp#1011

Comment 21

[Michal Novotny [:michal]]

Attachment: -w version of patch 313385

Comment 22

[Daniel Holbert [:dholbert]]

Comment on attachment 312793 [details]
reduced testcase 2 (doesn't always crash)

I can't currently reproduce the crash using "reduced testcase 2", with or without the patch.  (And even back when I could reproduce it, it was sporadic.)  

Noting this in the testcase's description, and marking it as obsolete.

Comment 23

[Daniel Holbert [:dholbert]]

FWIW, the patch does fix the crash for me, on "slightly reduced testcase (one HTML file)", attachment 312786 [details].

Comment 24

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

This is amazing work and looks like the right thing.

However, we're basically duplicating logic from the "  else if (NS_FRAME_IS_NOT_COMPLETE(frameReflowStatus)) {" case below. We should share the code instead, probably by making that code into its own standalone "if" statement below. Does that make sense?

Comment 25

[Michal Novotny [:michal]]

Attachment: new patch

Patch changed according to comment #14.

Condition for calling SplitLine() is different in both cases and I kept it in the new patch. But maybe the condition should be the same?

Comment 26

[Michal Novotny [:michal]]

Attachment: -w version of patch 313616

Comment 27

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

Yeah I think the condition for SplitLine should be the same, i.e. use the reflowingFirstLetter tests along both paths. You can also get rid of createContinuationFrame by just testing NS_FRAME_IS_NOT_COMPLETE(frameReflowStatus).

Comment 28

[Michal Novotny [:michal]]

Attachment: new patch

Comment 29

[Michal Novotny [:michal]]

Attachment: diff -w

Comment 30

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

Comment on attachment 313991 [details] [diff] [review]
diff -w

+      if (!NS_FRAME_IS_NOT_COMPLETE(frameReflowStatus)) {

Avoid double negatives, use NS_FRAME_IS_COMPLETE

Do you happen to have a small testcase that we could check in as a crashtest?

Comment 31

[Michal Novotny [:michal]]

Attachment: patch changed according to comment #30

Comment 32

[Michal Novotny [:michal]]

(In reply to comment #30)
> Do you happen to have a small testcase that we could check in as a crashtest?

I have reduced testcase in attachment #312786 [details] to 14kb and it is still crashing constantly on my computer. Further reducing makes reproducing unstable. If 14kb is OK, I'll try to write the crashtest.

Comment 33

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

14Kb should be fine. The main thing is that it needs to not load anything from the network and it needs to finish loading quickly in a fixed build. Thanks very very very very much!!!!

Comment 34

[Michal Novotny [:michal]]

Attachment: reduced testcase 3

Comment 35

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 4

Reduced the testcase a bit more.

Comment 36

[Michal Novotny [:michal]]

(In reply to comment #35)
> Created an attachment (id=314213) [details]
> reduced testcase 4
> 
> Reduced the testcase a bit more.
> 

I can't reproduce crash with this testcase.

Comment 37

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

We should land this patch before/while we worry about getting a good testcase.

Comment 38

[Daniel Holbert [:dholbert]]

Comment on attachment 314213 [details]
reduced testcase 4

> I can't reproduce crash with this testcase.

D'oh.  Ok, marking it obsolete.

Comment 39

[Daniel Holbert [:dholbert]]

Final patch (attachment 314108 [details] [diff] [review]) checked in.  Thanks for fixing this, Michal!

Checking in generic/nsBlockFrame.cpp;
/cvsroot/mozilla/layout/generic/nsBlockFrame.cpp,v  <--  nsBlockFrame.cpp
new revision: 3.945; previous revision: 3.944
done

Closing with in-testsuite? flag, as we still need to add a testcase for this.

Comment 40

[Michal Novotny [:michal]]

Attachment: example that crashes when exitPrintPreview() is called

I really don't know how to write the crashtest. I spent a lot of time on this without success. Problem is that I should somehow close preview window if doing preview doesn't crash.

I tried something simple like:

webBrowserPrint.printPreview(null, null, cb);
setTimeout(function () { webBrowserPrint.exitPrintPreview(); }, 1000);

But this doesn't work because no timer is executed until preview window is closed.

So I tried to implement nsIWebProgressListener interface and close print preview in onStateChange() when (aStateFlags & STATE_STOP) != 0. But this crashes firefox. Can somebody please have a look at attached example?

Comment 41

[Michal Novotny [:michal]]

Attachment: reduced testcase 5

Comment 42

[Daniel Holbert [:dholbert]]

Attachment: reftest patch (based on reduced testcase 5) (as assertion test)

For the life of me I can't get this to crash during a reftest-print reftest -- I tried reducing the widths so that print-previewing on a reftest-print-sized page would crash, but the reftest process still wouldn't crash.

However, I noticed that the reftest process *does* fail an assertion.  So, I'm just checking this in as an assertion test for now, per this attached patch.

Comment 43

[Daniel Holbert [:dholbert]]

(In reply to comment #42)
> For the life of me I can't get this to crash during a reftest-print reftest --
> I tried reducing the widths

FWIW, I tried editing reftest.js to use 8.5-by-11 printing surface, and it still wouldn't crash, even though I was crashing when printing/print-previewing at that page size.

Comment 44

[Daniel Holbert [:dholbert]]

(In reply to comment #42)
> However, I noticed that the reftest process *does* fail an assertion.

FWIW, The assertion this reftest fails is:
  http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/base/nsPresShell.cpp&rev=3.1107&root=/cvsroot#672

This assertion fails during a print-preview operation, too, shortly before the crash.

Comment 45

[Daniel Holbert [:dholbert]]

Assertion reftest checked in:
RCS file: /cvsroot/mozilla/layout/reftests/bugs/421710-1.html,v
done
Checking in 421710-1.html;
/cvsroot/mozilla/layout/reftests/bugs/421710-1.html,v  <--  421710-1.html
initial revision: 1.1
done
Checking in reftest.list;
/cvsroot/mozilla/layout/reftests/bugs/reftest.list,v  <--  reftest.list
new revision: 1.437; previous revision: 1.436
done

Marking in-testsuite+.

If we can ever get an automated reftest / crashtest that *crashes* on this bug in pre-patched builds, that would be awesome.  However, I'm giving up on that for now, as Michal and I have both already sunk too much of our lives into working on testcases for this bug. :)

Comment 46

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

Thanks guys!!

Comment 47

[Carsten Book [:Tomcat]]

verified fixed using the testcases and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 +  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041304 Minefield/3.0pre no crash on testcases.

--> Verified fixed