1.8 branch Regression? Crash login/loading Gmail account [@ GetNearestContainingBlock] (began 30 Jan 2008)

RESOLVED WONTFIX

Status

()

Core
Layout
--
critical
RESOLVED WONTFIX
11 years ago
7 years ago

People

(Reporter: François Gagné, Assigned: roc)

Tracking

(4 keywords)

1.8 Branch
x86
Windows XP
crash, qawanted, regression, topcrash
Points:
---
Bug Flags:
blocking1.8.1.13 -
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080201 BonEcho/2.0.0.12pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080201 BonEcho/2.0.0.12pre

Crash login/loading Gmail account [@ GetNearestContainingBlock]. It began on 30 Jan 2008 on the 1.8 branch.

Perhaps a regression from the Security fixes? http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-26&maxdate=2008-01-31&cvsroot=%2Fcvsroot

Talback from the 30 Jan 2008:
TB40850262K

Talback from the 1 Feb 2008:
TB40936513X
TB40936589X

Talback from the 2 Feb 2008:
TB40968364W


Reproducible: Sometimes

Steps to Reproduce:
1. Log into Gmail

Actual Results:  
Crash from time to time during the loading phase.
(Reporter)

Comment 1

11 years ago
Stack from TB40850262K:


GetNearestContainingBlock  [mozilla/layout/generic/nsHTMLReflowState.cpp, line 660]
nsHTMLReflowState::InitAbsoluteConstraints  [mozilla/layout/generic/nsHTMLReflowState.cpp, line 1045]
nsHTMLReflowState::InitConstraints  [mozilla/layout/generic/nsHTMLReflowState.cpp, line 1961]
nsHTMLReflowState::Init  [mozilla/layout/generic/nsHTMLReflowState.cpp, line 342]
nsHTMLReflowState::nsHTMLReflowState  [mozilla/layout/generic/nsHTMLReflowState.cpp, line 315]
nsAbsoluteContainingBlock::ReflowAbsoluteFrame  [mozilla/layout/generic/nsAbsoluteContainingBlock.cpp, line 521]
nsAbsoluteContainingBlock::Reflow  [mozilla/layout/generic/nsAbsoluteContainingBlock.cpp, line 208]
nsBlockFrame::Reflow  [mozilla/layout/generic/nsBlockFrame.cpp, line 1094]
nsContainerFrame::ReflowChild  [mozilla/layout/generic/nsContainerFrame.cpp, line 909]
CanvasFrame::Reflow  [mozilla/layout/generic/nsHTMLFrame.cpp, line 536]
nsContainerFrame::ReflowChild  [mozilla/layout/generic/nsContainerFrame.cpp, line 909]
nsHTMLScrollFrame::ReflowScrolledFrame  [mozilla/layout/generic/nsGfxScrollFrame.cpp, line 523]
nsHTMLScrollFrame::ReflowContents  [mozilla/layout/generic/nsGfxScrollFrame.cpp, line 571]
nsHTMLScrollFrame::Reflow  [mozilla/layout/generic/nsGfxScrollFrame.cpp, line 769]
nsContainerFrame::ReflowChild  [mozilla/layout/generic/nsContainerFrame.cpp, line 909]
ViewportFrame::Reflow  [mozilla/layout/generic/nsViewportFrame.cpp, line 240]
IncrementalReflow::Dispatch  [mozilla/layout/base/nsPresShell.cpp, line 915]
PresShell::ProcessReflowCommands  [mozilla/layout/base/nsPresShell.cpp, line 7075]
PresShell::FlushPendingNotifications  [mozilla/layout/base/nsPresShell.cpp, line 5465]
nsDocument::FlushPendingNotifications  [mozilla/content/base/src/nsDocument.cpp, line 4389]
nsHTMLDocument::FlushPendingNotifications  [mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1318]
nsGenericHTMLElement::GetOffsetRect  [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 624]
nsGenericHTMLElement::GetOffsetLeft  [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 826]
nsGenericHTMLElementTearoff::GetOffsetLeft  [mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 218]
XPCWrappedNative::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169]
XPC_WN_GetterSetter  [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1487]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1379]
js_InternalInvoke  [mozilla/js/src/jsinterp.c, line 1473]
JS_CallFunctionValue  [mozilla/js/src/jsapi.c, line 4353]
XPC_NW_GetOrSetProperty  [mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 596]
XPC_NW_GetProperty  [mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 615]
js_GetProperty  [mozilla/js/src/jsobj.c, line 3616]
js_Interpret  [mozilla/js/src/jsinterp.c, line 3695]
js_Invoke  [mozilla/js/src/jsinterp.c, line 1398]
nsXPCWrappedJSClass::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453]
nsXPCWrappedJS::CallMethod  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468]
SharedStub  [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1655]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1762]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2234]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2213]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2213]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2213]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2213]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2213]
nsXULElement::HandleChromeEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2899]
nsGlobalWindow::HandleDOMEvent  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 1720]
DocumentViewerImpl::LoadComplete  [mozilla/layout/base/nsDocumentViewer.cpp, line 1017]
nsDocShell::EndPageLoad  [mozilla/docshell/base/nsDocShell.cpp, line 4873]
nsWebShell::EndPageLoad  [mozilla/docshell/base/nsWebShell.cpp, line 673]
nsDocShell::OnStateChange  [mozilla/docshell/base/nsDocShell.cpp, line 4788]
nsDocLoader::FireOnStateChange  [mozilla/uriloader/base/nsDocLoader.cpp, line 1210]
nsDocLoader::doStopDocumentLoad  [mozilla/uriloader/base/nsDocLoader.cpp, line 844]
nsDocLoader::DocLoaderIsEmpty  [mozilla/uriloader/base/nsDocLoader.cpp, line 744]
nsDocLoader::OnStopRequest  [mozilla/uriloader/base/nsDocLoader.cpp, line 665]
nsLoadGroup::RemoveRequest  [mozilla/netwerk/base/src/nsLoadGroup.cpp, line 732]
PresShell::RemoveDummyLayoutRequest  [mozilla/layout/base/nsPresShell.cpp, line 7318]
PresShell::Destroy  [mozilla/layout/base/nsPresShell.cpp, line 2057]
DocumentViewerImpl::Hide  [mozilla/layout/base/nsDocumentViewer.cpp, line 2049]
nsDocShell::SetVisibility  [mozilla/docshell/base/nsDocShell.cpp, line 3860]
nsFrameList::DestroyFrame  [mozilla/layout/generic/nsFrameList.cpp, line 234]
nsFrameManager::RemoveFrame  [mozilla/layout/base/nsFrameManager.cpp, line 717]
DeletingFrameSubtree  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9856]
nsCSSFrameConstructor::ContentRemoved  [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10037]
Flags: blocking1.8.1.12?
Version: Trunk → 1.8 Branch
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080202 BonEcho/2.0.0.12pre

WFM with a new profile.

Updated

11 years ago
Keywords: crash
(Reporter)

Comment 3

11 years ago
Thus the 'Reproducible: Sometimes', here during normal browsing it crash around once a day. 3 out of the 4 crashes happened loading Gmail right after Firefox start up.
(In reply to comment #3)
> Thus the 'Reproducible: Sometimes'

Thus my WFM because I tested it multiple times and couldn't reproduce. Also, please don't request blocking on UNCONFIRMED bugs. Thanks.
Flags: blocking1.8.1.12?
Keywords: regression
(Reporter)

Comment 5

11 years ago
Sorry about that.

Here one more talkback TB40974974M from 30 minutes ago,


Something is going on, but I really don't know what is it, I'm not able to reproduce the problem when I try to. And then, unexpectedly, after 30 mins of testing and giving up, Firefox dies when loading Gmail ...

It seem having Gmail Notifier extension (https://addons.mozilla.org/en-US/firefox/addon/173) may help trigger the bug.
(Reporter)

Comment 6

11 years ago
Seem a old bug regressed: Bug 315850

The testcase https://bugzilla.mozilla.org/attachment.cgi?id=202499 crash everytime I load it on my setup with a new empty profile.

Updated

11 years ago
Keywords: qawanted
(Reporter)

Comment 7

11 years ago
Ok seem Bug 315850 was never fixed on branch :(

Could it be that Gmail updated their code a couple of days ago?

I can't reproduce using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 with the Gmail Notifier.
Depends on: 315850
François, are you using the newer or older version of GMail? Which language?
(In reply to comment #5)
> It seem having Gmail Notifier extension
> (https://addons.mozilla.org/en-US/firefox/addon/173) may help trigger the bug.

I can't seem to install that extension.

(Reporter)

Comment 11

11 years ago
Comment #9, I'm using the newer version of Gmail in English.

Gmail Notifier is a hypothesis, 4 out 5 crashes happened when using Gmail Notifier to load Gmail. Is it needed? I honestly don't know.

I guess you could try installing version 0.6.2.2 of Gmail Notifier. (https://addons.mozilla.org/en-US/firefox/addons/versions/173)
(Reporter)

Comment 12

11 years ago
Just hit it once more, TB41000736K , when restoring a session of 5 tabs, one of the tab had Gmail into it. (The restore was done by Tab Mix Plus)

(Reporter)

Comment 13

11 years ago
From the preliminary crash data from Firefox 2.0.0.12 it's the number 10 crash. (http://talkback-public.mozilla.org/reports/firefox/FF20012/index.html)

On my part I continue to crash about once per day or so.

TB41006094G, TB41126613K, TB41187547Z, TB41234777Q

TB41187547Z have a different stack.
Ugh, yeah, and the stacktrace doesn't seem to occur in FF20011, which makes it possible that this somehow regressed on the branch with some patch that went in.

Confirming, based on the fact this is is showing up on the topcrashers list.
The regression range in comment 0 doesn't show up anything that could have caused this, afaict.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: topcrash
Flags: blocking1.8.1.13?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.13+
(Reporter)

Comment 15

11 years ago
Good news!
Got the Gmail loading crash in a debug build.

Just before crashing it hits the following assertion:

###!!! ASSERTION: no placeholder frame: 'nsnull != placeholderFrame', file c:/mozilla-build/mozilla/layout/generic/nsHTMLReflowState.cpp, line 1039


From c:/mozilla-build/mozilla/layout/generic/nsHTMLReflowState.cpp :

1035:  // Get the placeholder frame
1036:  nsIFrame*     placeholderFrame;
1037:
1038:  aPresContext->PresShell()->GetPlaceholderFrameFor(frame, &placeholderFrame);
1039:  NS_ASSERTION(nsnull != placeholderFrame, "no placeholder frame");
1040:
1041:  // Find the nearest containing block frame to the placeholder frame,
1042:  // and return its content area left, top, right, and bottom edges
1043:  nsMargin  blockContentArea;
1044:  nsIFrame* blockFrame = GetNearestContainingBlock(placeholderFrame,
1045:                                                   blockContentArea);

Firefox then crash in GetNearestContainingBlock because 'placeholderFrame' is null.


aPresContext->PresShell()->GetPlaceholderFrameFor return null for placeholderFrame.


Here the value of 'frame':
-		frame	0x04917b6c	nsIFrame *
+		[nsAreaFrame]	{...}	nsAreaFrame
+		nsISupports	{...}	nsISupports
+		mRect	{x=0 y=0 width=24000 ...}	nsRect
+		mContent	0x04922a80	nsIContent *
+		mStyleContext	0x04917b1c {mParent=0x049172ec mChild=0x04917d8c mEmptyChild=0x04917c90 ...}	nsStyleContext *
+		mParent	0x049171e8	nsIFrame *
+		mNextSibling	0x04947d80 {mFrameLoader={...} mInnerView=0x0494b158 mDidCreateDoc='' ...}	nsIFrame *
		mState	12591376	unsigned int


I'm currently debugging the crash in VS2005, so if someone want to know some variables values, just ask.
On jan 25, a few days before the claimed regression date of Jan 30, Roc checked in bug 298420 with the comment "nsColumnSetFrame::GetContentInsertionFrame return nsnull when there is unexpectedly no child, instead of crashing."

Could that be where the null is coming from?

Can we fix GetNearestContainingBlock() to not crash on null? or is that just moving the problem around to other places that don't expect nulls?
Assignee: nobody → roc
> Could that be where the null is coming from?

Improbable, GMail should not be going anywhere near -moz-column stuff

> Can we fix GetNearestContainingBlock() to not crash on null? or is that just
> moving the problem around to other places that don't expect nulls?

Probably.
GMail uses tons of browser-specific stuff when they can improve things for one browser or another, but you're right that I don't see -moz-column in use.

(In reply to comment #16)
> in bug 298420 with the comment "nsColumnSetFrame::GetContentInsertionFrame

The check-in comment was misleading, it was bug 346405 (attachment 298420 [details] [diff] [review])
No fix yet. Punting to the next release. We *need* to look at this for 1.8.1.14.
Flags: blocking1.8.1.14+
Flags: blocking1.8.1.13-
Flags: blocking1.8.1.13+
Created attachment 308044 [details] [diff] [review]
hacky fix (missing semicolon)

(In reply to comment #17)
> > Can we fix GetNearestContainingBlock() to not crash on null? or is that just
> > moving the problem around to other places that don't expect nulls?
> 
> Probably.

I disagree -- that in and of itself probably wouldn't fix the bug -- we also pass placeholderFrame into CalculateHypotheticalBox a few lines below ( http://tinyurl.com/2lo82u ), and that function would probably crash on a null placeholderFrame, too.

This fix avoids the crasy with a slightly different strategy -- use the original frame instead of its placeholder frame, in the rare (and unexpected) case where there is no placeholder frame.

Not sure how well this works, but I think it won't crash, at least...
Created attachment 308053 [details] [diff] [review]
hacky fix v2?

oops -- adding a semicolon at the end of the NS_NOTREACHED line. :)
Attachment #308044 - Attachment description: hacky fix? → hacky fix (missing semicolon)
Attachment #308044 - Attachment is obsolete: true
roc, would something like that work for the branch so we can fix this crash regression?
(In reply to comment #20)
> (In reply to comment #17)
> > > Can we fix GetNearestContainingBlock() to not crash on null? or is that just
> > > moving the problem around to other places that don't expect nulls?
> > 
> > Probably.
> 
> I disagree -- that in and of itself probably wouldn't fix the bug -- we also
> pass placeholderFrame into CalculateHypotheticalBox a few lines below (
> http://tinyurl.com/2lo82u ), and that function would probably crash on a null
> placeholderFrame, too.

Sorry I meant "Probably that is just moving the problem around to other places that don't expect nulls"
Samuel, there's no way to tell really without debugging the crash properly. I guess you can *try* it and if it makes this bug go away, we could land it on branch; it can't really hurt.

I would not want to take that fix on trunk.
It would be nice if we figured out a way to reproduce this bug on demand. It is going to be hard to verify a fix otherwise.
I guess we live with this new topcrash regression on the branch, I don't see a proposed fix coming.
Flags: blocking1.8.1.15+
wontfixing 1.8-branch bug.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
Summary: Regression? Crash login/loading Gmail account [@ GetNearestContainingBlock] (began 30 Jan 2008) → 1.8 branch Regression? Crash login/loading Gmail account [@ GetNearestContainingBlock] (began 30 Jan 2008)
Crash Signature: [@ GetNearestContainingBlock]
You need to log in before you can comment on or make changes to this bug.