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

VERIFIED FIXED in mozilla0.9.7



17 years ago
17 years ago


(Reporter: jay, Assigned: Marc Attinasi)


({crash, topcrash})

Windows NT
crash, topcrash

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(4 attachments, 1 obsolete attachment)



17 years ago
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 	 hyatt@netscape.com mozilla0.9.6 	 2001-10-16
		 102778 	 RESO 	 DUPL 	 attinasi@netscape.com 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: 

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 552]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp  line 5020]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp  line 1038]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3659]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3540]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3465]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 3410]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2479]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 2142]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 827]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp  line 570]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 891]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp  line 540]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp  line 392]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp  line 653]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1027]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1138]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 1035]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp  line 1002]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 944]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp  line 753]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 737]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 576]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 2700]
line 3917]
line 2756]
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp  line 669]
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp  line 1384]
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp  line 1458]
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp  line 843]
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1240]
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 2279]
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp  line 2424]
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp  line 1412]
[d:\builds\seamonkey\mozilla\layout\html\document\src\nsFrameFrame.cpp  line 697]
	 nsHTMLFrameInnerFrame::`scalar deleting destructor'
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrame.cpp  line 471]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineBox.cpp  line 292]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 329]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1172]
[d:\builds\seamonkey\mozilla\layout\base\src\nsFrameList.cpp  line 131]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 135]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp  line 157]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp  line 458]
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp  line 1734]
[d:\builds\seamonkey\mozilla\content\base\src\nsDocumentViewer.cpp  line 1224]
 	Source File :
line : 552
     (37440408)	URL: www.cnn.com
URL: www.slashdot.org
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/
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
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
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
Comments: I create a new tab with ctrl+t and on new tab  I go to bookmark
     (37324999)	URL: www.cnn.com
Comments: trying to surf thru www.subdimension.com/nettools/anonymizit/index.shtml
URL: www.cnn.com
URL: www.cnn.com
URL: www.cnn.com
Comments: surfing thru www.subdimension/nettools/anonymizit/index.shtml
URL: http://tim.oreilly.com/sci-fi/herbert
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  [:)] 
URL: http://search.netscape.com
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
URL: http://www.rbc.ru
URL: www.mozilla.org
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
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

17 years ago
adding crash, topcrash keywords and reassigning to hyatt.
Assignee: evaughan → hyatt
Keywords: crash, topcrash

Comment 2

17 years ago
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

17 years ago
See also bug 104804.

Comment 4

17 years ago
*** Bug 110209 has been marked as a duplicate of this bug. ***
*** Bug 109256 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
Early M096 branch reports show six incidents in 2001111413 and 1617 builds. 
Updating summary. No comments.
Summary: Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle] → M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle]
*** Bug 111147 has been marked as a duplicate of this bug. ***
*** Bug 111741 has been marked as a duplicate of this bug. ***


17 years ago
Target Milestone: --- → mozilla1.1

Comment 10

17 years ago
Created attachment 59770 [details]
Mozilla 0.9.6 crashes split by unique stack traces

Comment 11

17 years ago
Created attachment 59771 [details]
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

17 years ago
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...
Assignee: hyatt → attinasi
Component: HTMLFrames → Layout
QA Contact: amar → petersen
Target Milestone: mozilla1.1 → ---

Comment 13

17 years ago
getting into current milestone
Priority: -- → P1
Target Milestone: --- → mozilla0.9.7
*** Bug 112828 has been marked as a duplicate of this bug. ***

Comment 15

17 years ago
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
Depends on: 52334
Summary: M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle] → [DEPEND 52334] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle]

Comment 16

17 years ago
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);
      mAveCharWidth = 0;
#if defined(_WIN32) || defined(XP_OS2)

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

17 years ago
Created attachment 59893 [details] [diff] [review]
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

17 years ago
Noting the uncertainty of the dependence on bug 52334 (with a '?' in summary).
Summary: [DEPEND 52334] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle] → [DEPEND 52334?] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle]

Comment 19

17 years ago
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

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

Comment 21

17 years ago
Crap. Ingore that. This bug is older than that. Sorry for the spam.
I've added a URL that crashed for me 100% with today's trunk win32 build.


Comment 24

17 years ago
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

17 years ago
Created attachment 60552 [details] [diff] [review]
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

17 years ago
Updating summary...
Summary: [DEPEND 52334?] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle] → [PATCH] M096 Trunk crashing again [@ nsTextFrame::TextStyle::TextStyle]
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 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)
Attachment #60552 - Flags: review+

Comment 29

17 years ago
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

17 years ago
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

17 years ago
Created attachment 60711 [details] [diff] [review]
Patch: moves the new call to nsIDocShell instead of nsIWebShell
Attachment #60552 - Attachment is obsolete: true

Comment 32

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

dbaron said his review still applies
Attachment #60711 - Flags: review+


17 years ago
Attachment #60711 - Flags: superreview+
Comment on attachment 60711 [details] [diff] [review]
Patch: moves the new call to nsIDocShell instead of nsIWebShell


Comment 34

17 years ago
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  <-- 
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

Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 35

17 years ago
>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 

Comment 36

17 years ago
verified fixed. the haven't been any crashes since 12/6 according to the latest
talkback data.
Crash Signature: [@ nsTextFrame::TextStyle::TextStyle]
You need to log in before you can comment on or make changes to this bug.