108105 - [PATCH] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle]

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Jay Patel [:jay]]

A similar crash was fixed recently: bug 101746, but this stack signature is
still showing up with recent MozillaTrunk builds...so logging a new bug.  Here's
the latest info from Talkback:

nsTextFrame::TextStyle::TextStyle   74
		 101746 	 RESO 	 FIXE 	 [e-mail] mozilla0.9.6 	 2001-10-16
		 102778 	 RESO 	 DUPL 	 [e-mail] mozilla0.9.6 	 2001-10-07 
BBID range: 37004020 - 37458573
Min/Max Seconds since last crash: 14 - 89398
Min/Max Runtime: 14 - 180862
Crash data range: 2001-10-22 to 2001-10-31
Build ID range: 2001102121 to 2001102911
Keyword List : button(4), load(8), browser(5), 
Stack Trace: 

	 nsTextFrame::TextStyle::TextStyle
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 552]
	 nsTextFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 5020]
	 nsLineLayout::ReflowFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp  line 1038]
	 nsBlockFrame::ReflowInlineFrame
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3659]
	 nsBlockFrame::DoReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3540]
	 nsBlockFrame::DoReflowInlineFramesAuto
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3465]
	 nsBlockFrame::ReflowInlineFrames
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3410]
	 nsBlockFrame::ReflowLine
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2479]
	 nsBlockFrame::ReflowDirtyLines
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2142]
	 nsBlockFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 827]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
	 CanvasFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp  line 570]
	 nsBoxToBlockAdaptor::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 891]
	 nsBoxToBlockAdaptor::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 540]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
	 nsScrollBoxFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 392]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
	 nsContainerBox::LayoutChildAt
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 653]
	 nsGfxScrollFrameInner::LayoutBox
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1027]
	 nsGfxScrollFrameInner::Layout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1138]
	 nsGfxScrollFrame::DoLayout
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1035]
	 nsBox::Layout
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
	 nsBoxFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 944]
	 nsGfxScrollFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 753]
	 nsContainerFrame::ReflowChild
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
	 ViewportFrame::Reflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 576]
	 PresShell::InitialReflow
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 2700]
	 HTMLContentSink::StartLayout
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp 
line 3917]
	 HTMLContentSink::DidBuildModel
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp 
line 2756]
	 CNavDTD::DidBuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp  line 669]
	 nsParser::DidBuildModel
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp  line 1384]
	 nsParser::Terminate
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp  line 1458]
	 nsHTMLDocument::StopDocumentLoad
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp  line 843]
	 DocumentViewerImpl::Stop
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1240]
	 nsDocShell::Stop
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 2279]
	 nsDocShell::Destroy
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 2424]
	 nsWebShell::Destroy
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp  line 1412]
	 nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp  line 697]
	 nsHTMLFrameInnerFrame::`scalar deleting destructor'
	 nsFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp  line 471]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 nsLineBox::DeleteLineList
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp  line 292]
	 nsBlockFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 329]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 nsBoxFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1172]
	 nsFrameList::DestroyFrames
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
	 nsContainerFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
	 ViewportFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 157]
	 FrameManager::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 458]
	 PresShell::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 1734]
	 DocumentViewerImpl::Destroy
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1224]
 
 	Source File :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/base/src/nsTextFrame.cpp
line : 552
     (37440408)	URL: www.cnn.com
(37414020)
URL: www.slashdot.org
(37414020)
Comments: Opened a link in a new tab. As the new tab was loading  I
right-clicked on the tabl and chose "Close Tab". The browser proceeded to die.
     (37412032)	URL: http://www.slashdot.org/
(37412032)
Comments: I started chofmann's browser buster in a new tab  then selected Close
Other Tabs from another tab while a page was loading.
     (37388042)	Comments: Switching off javascript for browser support in the preferences.
     (37355109)	URL: http://news.bbc.co.uk
(37355109)
Comments: Loading the web page...Also  using tabs  but news.bbc.co.uk was the
only page loading at the time  and it was the selected tab
     (37341950)	URL: http://www.del.dennon.com
(37341950)
Comments: My son hit the F9 key a bunch of times while one of the sidebars was
trying to load.
     (37338834)	URL: www.cnn.com
(37331574)
Comments: I create a new tab with ctrl+t and on new tab  I go to bookmark
     (37324999)	URL: www.cnn.com
(37324999)
Comments: trying to surf thru www.subdimension.com/nettools/anonymizit/index.shtml
(37324770)
URL: www.cnn.com
(37289101)
URL: www.cnn.com
(37288912)
URL: www.cnn.com
(37288912)
Comments: surfing thru www.subdimension/nettools/anonymizit/index.shtml
(37286630)
URL: http://tim.oreilly.com/sci-fi/herbert
(37273374)
Comments: Closed Tab
     (37233900)	URL: news.bbc.co.uk
     (37187351)	Comments: pushing back button continuosly. All the pages in the history were
identical and had frames.
     (37186931)	Comments: in "edit" - "preferences" - "navigaotor" - "tabbed browsing"tried
to mark for "Load links in the background" and "Control+Enter in the URL bar"
Clicked "OK" - and that's what was not considered ok from Mozilla )-:CheersArnvid
     (37169240)	Comments: Crash when closing sidebar via F9 while HTML 4.01 sidebar was loading
     (37159398)	Comments: setting font preferencies  disallowing sites to use other fonts
     (37157744)	Comments: nothing  [:)] 
(37137838)
URL: http://search.netscape.com
(37137838)
Comments: Just clicked on the Search button in the browser's UI.
     (37137615)	URL: .
     (37137615)	Comments: Just closing the browser.
     (37135436)	Comments: Clicked on a bugzilla link to bring a window to the front.
     (37134926)	URL: .
     (37134926)	Comments: Pressed the search button.
     (37134517)	URL: .
     (37134517)	Comments: Just loading www.netflix.com
(37110470)
URL: http://www.rbc.ru
(37108632)
URL: www.mozilla.org
(37108632)
Comments: Just typed 'mozilla.org' in and hit enter.
     (37100096)	URL: microsoft.com
     (37100096)	Comments: I was browsing MS's site (in a tab). I clicked a link and before
the page was done loading  I blicked the back button. Disk grind  then moz
crashes. there was nothing special on the site that may have caused it so it
looks like it's Moz's fault that the
     (37100096)	Comments:  actual HTML.
     (37078953)	URL: http://news.bbc.co.uk
(37075088)
URL: http://news.bbc.co.uk

If this is a regression of fixed bug 101746, please feel free to mark this a dup
and reopen that one.  Cc'ing some people from that bug...

Comment 1

[Jay Patel [:jay]]

adding crash, topcrash keywords and reassigning to hyatt.

Comment 2

[rbs]

Might actually be another manifestation of bug 103997 -- StartLayout() is 
kicking off during destruction as per Marc's comments of 2001-10-11 17:46 in 
that bug.

Comment 3

[rbs]

See also bug 104804.

Comment 4

[rbs]

*** Bug 110209 has been marked as a duplicate of this bug. ***

Comment 5

[Ashley Bischoff (blog at handcoding.com)]

*** Bug 109256 has been marked as a duplicate of this bug. ***

Comment 6

[greer]

Early M096 branch reports show six incidents in 2001111413 and 1617 builds. 
Updating summary. No comments.

Comment 7

[Matthias Versen [:Matti]]

*** Bug 111147 has been marked as a duplicate of this bug. ***

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

A good place to crash, http://netscape.businessweek.com, then click on the tab.

Comment 9

[Boris Zbarsky [:bzbarsky]]

*** Bug 111741 has been marked as a duplicate of this bug. ***

Comment 10

[Jay Patel [:jay]]

Attachment: Mozilla 0.9.6 crashes split by unique stack traces

Comment 11

[Jay Patel [:jay]]

Attachment: MozillaTrunk crashes split by unique stack traces

This is the #3 topcrasher for Mozilla 0.9.6 and is also a topcrasher for the
MozillaTrunk.  I'm attaching complete Talkback topcrash reports so people can
look into this.  

The target milestone is set to mozilla1.1 ...are we sure we want to wait until
then to fix such a common crash?

Comment 12

[John Morrison]

The user comments refer to a number of user actions, but the crash is deep in 
layout code, although the code is largely unchanged for a long time. Perhaps 
some other change exposed a latent bug. 

Reassigning to default layout owner. top crash and all...

Comment 13

[rubydoo123]

getting into current milestone

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 112828 has been marked as a duplicate of this bug. ***

Comment 15

[Marc Attinasi]

I get a different stack, and it definitely points to a know problem where we are
StartLayout is kicked off during destruction (as rbs commented). Like bug
103997, this is related to the way we handle frames in the layout rather than
the content, and will be fixed bu jst's fix to bug 52334. This is probably a
'dup' of 52334, in the sense that fixing that will fix this. Marking depends-on
for now.

Here is the stack I got on http://netscape.businessweek.com (clicked a tab):

NTDLL! 77fa018c()
nsWindow::Create(nsWindow * const 0x05ac3e34, nsIWidget * 0x041269a4, const
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x02ea45e0 HandleEvent(nsGUIEvent
*), nsIDeviceContext * 0x04126cd0, nsIAppShell * 0x00000000, nsIToolkit *
0x00000000, nsWidgetInitData * 0x0012eb40) line 1210
nsView::CreateWidget(nsView * const 0x05ac23e0, const nsID & {...},
nsWidgetInitData * 0x0012eb40, void * 0x00000000, int 1, int 1) line 911
nsScrollPortView::CreateScrollControls(nsScrollPortView * const 0x05ac2440, void
* 0x00000000) line 177
nsScrollBoxFrame::CreateScrollingView(nsIPresContext * 0x04127d70) line 309
nsScrollBoxFrame::Init(nsScrollBoxFrame * const 0x04ec140c, nsIPresContext *
0x04127d70, nsIContent * 0x03fe5090, nsIFrame * 0x04ec11ac, nsIStyleContext *
0x04d19290, nsIFrame * 0x00000000) line 115
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x04127d70,
nsFrameConstructorState & {...}, nsIContent * 0x03fe5090, nsIFrame * 0x04ec11ac,
nsIStyleContext * 0x04d19290, nsIFrame * 0x00000000, nsIFrame * 0x04ec140c) line
6515 + 32 bytes
nsCSSFrameConstructor::BeginBuildingScrollFrame(nsIPresShell * 0x041276b0,
nsIPresContext * 0x04127d70, nsFrameConstructorState & {...}, nsIContent *
0x03fe5090, nsIStyleContext * 0x04ec1118, nsIFrame * 0x04ec1064, nsIAtom *
0x005795f0, nsIDocument * 0x05783ad0, int 1, nsIFrame * & 0x04ec11ac,
nsCOMPtr<nsIStyleContext> & {...}, nsIFrame * & 0x00000000, nsIFrame *
0x00000000) line 5
nsCSSFrameConstructor::ConstructRootFrame(nsCSSFrameConstructor * const
0x04126860, nsIPresShell * 0x041276b0, nsIPresContext * 0x04127d70, nsIContent *
0x03fe5090, nsIFrame * & 0x00000000) line 3689
StyleSetImpl::ConstructRootFrame(StyleSetImpl * const 0x04126930, nsIPresContext
* 0x04127d70, nsIContent * 0x03fe5090, nsIFrame * & 0x00000000) line 1397 + 39 bytes
PresShell::InitialReflow(PresShell * const 0x041276b0, int 16665, int 12435)
line 2663
HTMLContentSink::StartLayout() line 3932
HTMLContentSink::DidBuildModel(HTMLContentSink * const 0x0577e320, int 0) line 2769
CNavDTD::DidBuildModel(CNavDTD * const 0x0459b040, unsigned int 2152596471, int
1, nsIParser * 0x05781f00, nsIContentSink * 0x0577e320) line 666 + 14 bytes
nsParser::DidBuildModel(unsigned int 2152596471) line 1387 + 55 bytes
nsParser::Terminate() line 1472
nsHTMLDocument::StopDocumentLoad(nsHTMLDocument * const 0x05783ad0) line 849
DocumentViewerImpl::Stop(DocumentViewerImpl * const 0x05787840) line 1324
nsDocShell::Stop(nsDocShell * const 0x057354b0, unsigned int 3) line 2297
nsDocShell::Destroy(nsDocShell * const 0x057354b4) line 2442
nsWebShell::Destroy(nsWebShell * const 0x057354b4) line 1412
nsHTMLFrameInnerFrame::~nsHTMLFrameInnerFrame() line 700
nsHTMLFrameInnerFrame::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsFrame::Destroy(nsFrame * const 0x04de5b54, nsIPresContext * 0x0557dd70) line
479 + 52 bytes
nsFrameList::DestroyFrames(nsIPresContext * 0x0557dd70) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x04de5b14, nsIPresContext *
0x0557dd70) line 135
nsFrameList::DestroyFrames(nsIPresContext * 0x0557dd70) line 131
nsContainerFrame::Destroy(nsContainerFrame * const 0x04de5898, nsIPresContext *
0x0557dd70) line 135
nsLineBox::DeleteLineList(nsIPresContext * 0x0557dd70, nsLineList & {...}) line 292
nsBlockFrame::Destroy(nsBlockFrame * const 0x04de5580, nsIPresContext *
0x0557dd70) line 327 + 16 bytes
nsFrameList::DestroyFrame(nsIPresContext * 0x0557dd70, nsIFrame * 0x04de5580)
line 217
CanvasFrame::RemoveFrame(CanvasFrame * const 0x04de4f08, nsIPresContext *
0x0557dd70, nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x04de5580)
line 370
FrameManager::RemoveFrame(FrameManager * const 0x055494c0, nsIPresContext *
0x0557dd70, nsIPresShell & {...}, nsIFrame * 0x04de4f08, nsIAtom * 0x00000000,
nsIFrame * 0x04de5580) line 857
nsCSSFrameConstructor::ReconstructDocElementHierarchy(nsCSSFrameConstructor *
const 0x05531ea0, nsIPresContext * 0x0557dd70) line 7183 + 61 bytes
StyleSetImpl::ReconstructDocElementHierarchy(StyleSetImpl * const 0x05533b20,
nsIPresContext * 0x0557dd70) line 1404
PresShell::ReconstructFrames() line 5223 + 41 bytes
PresShell::StyleSheetAdded(PresShell * const 0x05530d38, nsIDocument *
0x05560210, nsIStyleSheet * 0x05aed1f0) line 5235
nsDocument::InsertStyleSheetAt(nsDocument * const 0x05560210, nsIStyleSheet *
0x05aed1f0, int 0, int 1) line 1389
CSSLoaderImpl::InsertSheetInDoc(nsICSSStyleSheet * 0x05aed1f0, int 0, nsIContent
* 0x0576b7c0, int 1, nsICSSLoaderObserver * 0x00000000) line 1164
CSSLoaderImpl::SheetComplete(nsICSSStyleSheet * 0x05aed1f0, SheetLoadData *
0x0576b5d0) line 867
CSSLoaderImpl::ParseSheet(nsIUnicharInputStream * 0x05aeb630, SheetLoadData *
0x0576b5d0, int & 1, nsICSSStyleSheet * & 0x05aed1f0) line 922
CSSLoaderImpl::DidLoadStyle(nsIStreamLoader * 0x0576b4f0, nsString * 0x05aeb270,
SheetLoadData * 0x0576b5d0, unsigned int 0) line 957 + 27 bytes
SheetLoadData::OnStreamComplete(SheetLoadData * const 0x0576b5d0,
nsIStreamLoader * 0x0576b4f0, nsISupports * 0x00000000, unsigned int 0, unsigned
int 3784, const char * 0x04df9e40) line 714
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0576b4f4, nsIRequest *
0x05733810, nsISupports * 0x00000000, unsigned int 0) line 137
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x05733814, nsIRequest *
0x04713794, nsISupports * 0x00000000, unsigned int 0) line 2316
nsOnStopRequestEvent::HandleEvent() line 177
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x04c7c6e4) line 80
PL_HandleEvent(PLEvent * 0x04c7c6e4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x004fc970) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x009e0160, unsigned int 49687, unsigned int 0,
long 5228912) line 1071 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
nsAppShellService::Run(nsAppShellService * const 0x00539480) line 303
main1(int 1, char * * 0x00481880, nsISupports * 0x00000000) line 1304 + 32 bytes
main(int 1, char * * 0x00481880) line 1630 + 37 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 16

[Marc Attinasi]

I wonder if that  http://netscape.businessweek.com link is unrelated to this.
(Also, note that bug 112886 has the same stack that I found on
http://netscape.businessweek.com).  I think it is unrelated because the stacks
differ, and I cannot dup the problem on any of the URLs listed in the talkbacks.

The reported stack looks to be croaking around here:

      deviceContext->GetMetricsFor(*plainFont, langGroup, mNormalFont);
      aRenderingContext.SetFont(mNormalFont); 
      mNormalFont->GetSpaceWidth(mSpaceWidth);
      mAveCharWidth = 0;
#if defined(_WIN32) || defined(XP_OS2)
      mNormalFont->GetAveCharWidth(mAveCharWidth);
#endif

so I am wondering if this is a case of GetMetricsFor setting mNormalFont to null
(I seem to remember this case happening before but the details escape me).  I'd
like to bullet-proof thi method and see if that helps, any comments on that?

Comment 17

[Marc Attinasi]

Attachment: wallpaper: check for null fonts

Proposed wallpaper for the stacks in the talkback. I cannot dup this, but I
think I have seen this problem before, and anyway the code is not checking for
nulls here (though it may be that it should not ever get nulls).

Comment 18

[Marc Attinasi]

Noting the uncertainty of the dependence on bug 52334 (with a '?' in summary).

Comment 19

[rbs]

Might also be related to bug 105619. When I hit this crash, the nsFont.name
string (and the entire font struct is general) from the Style System is garbage.

Comment 20

[Brian Nesse (gone)]

The other "font" related bug it could possibly tied to would be bug 108939.

Comment 21

[Brian Nesse (gone)]

Crap. Ingore that. This bug is older than that. Sorry for the spam.

Comment 22

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

This seems like a duplicate of bug 104804.  See also
http://bugzilla.mozilla.org/show_bug.cgi?id=101554#c26

Comment 23

[[e-mail] (gone - use [e-mail] instead)]

I've added a URL that crashed for me 100% with today's trunk win32 build.

http://info.netscape.com/fwd/bnwooobwkh1/http://netscape.businessweek.com:80/tec
hnology/tc_special/rethink_tech.htm

Comment 24

[Marc Attinasi]

Stephen, that URL you posted crashes me too, but with the stack I posted in
comment http://bugzilla.mozilla.org/show_bug.cgi?id=108105#c15

Fortunately, I have a fix for that cookin' now. If JST finishes his work on bug
52334 it will not be necessary, but I figured it was good insurance to take care
of the problem in layout in case he didn't finish before 0.9.7 closed. Patch
soon (for the 'other' crash at comment #15).

Comment 25

[Marc Attinasi]

Attachment: PATCH to prevent crash when an IFrame is being destroyed during layout

This patch fixes the 'other' stack, where we are trying to layout an IFRAME
after it has been destroyed. It is a simple check to see if the WebShell is
being destroyed (that was already a protected memeber of DocShell, I just
exposed it) and avoid doing starting layout if it is. This is the least
intrusive way I could think to fix this terrible architectural problem where
stopping a document load because and IFRAME is being destroyed will
synchronously causes a document to be built and layout to be initiated.

Comment 26

[Marc Attinasi]

Updating summary...

Comment 27

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

Patch looks fine to me, although I wonder whether this really belongs on
nsIWebShell, or whether it should be on nsIDocShell or something else.

Comment 28

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

Comment on attachment 60552 [details] [diff] [review]
PATCH to prevent crash when an IFrame is being destroyed during layout

r=dbaron, except I think you should ask a docshell owner (adamlock?  rpotts?)
on what interface this should really be (and you still have my r= if you move
the same thing to another interface and/or to nsDocShell at their request)

Comment 29

[Adam Lock]

nsIWebShell is an evil interface. It's probably better to go on nsIDocShell and
be implemented by the nsDocShell class. Otherwise the patch looks fine in
principle, though it would be better to use NS_ENSURE_ARG_POINTER in the pointer
check for IsBeingDestroyed.

Comment 30

[Marc Attinasi]

OK, I'll move it to nsIDocShell. I don't understand the difference between the
interfaces anyway, but I'll assume you guys do ;)

Comment 31

[Marc Attinasi]

Attachment: Patch: moves the new call to nsIDocShell instead of nsIWebShell

Comment 32

[Marc Attinasi]

Comment on attachment 60711 [details] [diff] [review]
Patch: moves the new call to nsIDocShell instead of nsIWebShell

dbaron said his review still applies

Comment 33

[Johnny Stenback (:jst)]

Comment on attachment 60711 [details] [diff] [review]
Patch: moves the new call to nsIDocShell instead of nsIWebShell

sr=jst

Comment 34

[Marc Attinasi]

Patches checked in (including the null-check wallpaper).

Checking in base/nsDocShell.cpp;
/cvsroot/mozilla/docshell/base/nsDocShell.cpp,v  <--  nsDocShell.cpp
new revision: 1.394; previous revision: 1.393

Checking in base/nsIDocShell.idl;
/cvsroot/mozilla/docshell/base/nsIDocShell.idl,v  <--  nsIDocShell.idl
new revision: 1.59; previous revision: 1.58

Checking in nsHTMLContentSink.cpp;
/cvsroot/mozilla/content/html/document/src/nsHTMLContentSink.cpp,v  <-- 
nsHTMLContentSink.cpp
new revision: 3.507; previous revision: 3.506

Checking in nsTextFrame.cpp;
/cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v  <--  nsTextFrame.cpp
new revision: 1.341; previous revision: 1.340

Comment 35

[rbs]

>Checking in nsTextFrame.cpp;
>/cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v  <--  nsTextFrame.cpp
>new revision: 1.341; previous revision: 1.340

This one doesn't look like it will help. If a crash were to happen, the null 
check there would just be delaying it (since mNormalFont is required later on 
for measurements/painting). Seems the correct fix had made the check 
unnecessary.

Comment 36

[Jay Patel [:jay]]

verified fixed. the haven't been any crashes since 12/6 according to the latest
talkback data.