Crash [@ nsDisplayList::GetBottom]

VERIFIED FIXED in mozilla1.9.2a1

Status

()

defect
P2
critical
VERIFIED FIXED
10 years ago
8 years ago

People

(Reporter: jruderman, Assigned: tnikkel)

Tracking

(Blocks 1 bug, 6 keywords)

Trunk
mozilla1.9.2a1
x86
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed1.9.1b99], crash signature)

Attachments

(3 attachments)

###!!! ASSERTION: leaf items can't be anonymous: 'list', file /Users/jruderman/central/layout/base/nsDisplayList.cpp, line 465

Crash [@ nsDisplayList::GetBottom]

My guess is that this is a recent regression, perhaps from bug 485275.
This is indeed caused by bug 485275. This bug can be assigned to me (I don't have permissions to do that myself).

Looks like the best way to solve this is to make nsDisplaySolidColor be based on a frame again. The trigger of this bug is a call to SortByContentOrder which sorts a display list by comparing positions in the content tree, and since the code assumes one of GetUnderlyingFrame or GetList will be non-null, this will fail either way. I think there will be more places where not having a frame for solid color items causes problems. Fixing bug 488242 is going to make solid color items long lived and part of the standard page drawing (instead of fallback or while transitioning between pages) and I've already run into another crash caused by not having a frame for solid color items in fixing bug 488242.

The only case where we will not have a frame to pass to the nsDisplaySolidColor constructor would be on transition between pages in nsSubDocumentFrame::BuildDisplayList. In this case we could substitute the nsSubDocumentFrame itself.
Assignee: nobody → tnikkel
Blocks: 485275
Keywords: regression
490193 is basically the same bug.

> In this case we could substitute the nsSubDocumentFrame itself.

That sounds good. To make things slightly simpler/more consistent, I suggest we always use the subdocument frame as the frame for the solid color created by a subdocument frame.
Blocks: 490193
tn, you should have editbugs permission now.
I decided to use the root frame of the subdocument if it is available to reduce the incongruity between the underlying frame and what we draw. For example the bounds of the nsSubDocumentFrame don't quite match what we need to draw. Also the crash in this bug came about when trying to sort the display items by the content tree structure; if we change the document that the underlying frame is from we will get a different sort. (Actually, I'm not sure that Sort in nsDisplayList.cpp is aware that it might be sorting display items with underlying frames from more than one document.) If I haven't convinced you I can use the nsSubDocumentFrame.

I will take a look at the other uses of GetUnderlyingFrame to see if any problems might be caused by using the nsSubDocumentFrame instead of the root frame of the subdocument.
Attachment #374866 - Flags: review?(roc)
> (Actually, I'm not sure that Sort in
> nsDisplayList.cpp is aware that it might be sorting display items with
> underlying frames from more than one document.)

Yes, that's a bug. What we should do is make nsSubdocumentFrame's nsDisplayClip's mFrame set to the nsSubdocumentFrame and include the nsDisplaySolidColor, then ExplodeAnonymousChildLists won't flatten it and the list will be sorted as an atomic unit using the nsSubdocumentFrame to generate the sort key, so the right content will be used. But that's not this bug, it's another, older bug.
I looked through the uses of the underlying frame for display item's and I
think we should be ok using the nsSubDocumentFrame if the subdocument is
loading.
Flags: blocking1.9.1?
Any chance this will get checked in today?  There's now over 14,000 reports against this bug and I'm frequently encountering it.
Keywords: topcrash
Comment on attachment 374866 [details] [diff] [review]
patch
[Checkin: Comment 8]


http://hg.mozilla.org/mozilla-central/rev/cb26c581d5f3
Attachment #374866 - Attachment description: patch → patch [Checkin: Comment 8]
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 1.9.1 landing: needs approval or blocking]
Target Milestone: --- → mozilla1.9.2a1
This is caused by a patch (bug 485275) that hasn't landed on 1.9.1 (yet), so I removed the 1.9.1 landing and blocking stuff, hope I'm not overstepping my bounds.
Flags: blocking1.9.1?
Whiteboard: [needs 1.9.1 landing: needs approval or blocking]
Since bug 485275 is clearly destined for 1.9.1, we need to make sure we don't forget about this followup. Blocking is a good way to do that.
Flags: blocking1.9.1?
Comment on attachment 374866 [details] [diff] [review]
patch
[Checkin: Comment 8]


(In reply to comment #8)
> http://hg.mozilla.org/mozilla-central/rev/cb26c581d5f3

This probably was after fixing context for
{
patching file layout/base/nsDisplayList.cpp
Hunk #1 FAILED at 492
1 out of 1 hunks FAILED
}
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Attachment #377787 - Flags: approval1.9.1?
Attachment #377787 - Flags: approval1.9.1?
Comment on attachment 377787 [details] [diff] [review]
1.9.1 patch
[Checkin: Comment 14]

Blockers don't need approval!
Whiteboard: [needs 1.9.1 landing]
Comment on attachment 377787 [details] [diff] [review]
1.9.1 patch
[Checkin: Comment 14]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/df1677120450
Attachment #377787 - Attachment description: 1.9.1 patch → 1.9.1 patch [Checkin: Comment 14]
Keywords: fixed1.9.1
Whiteboard: [needs 1.9.1 landing] → [fixed1.9.1b5]
Verified fixed on trunk and 1.9.1 with following builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090522 Minefield/3.6a1pre ID:20090522032716

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090521 Shiretoko/3.5pre ID:20090521135222
Status: RESOLVED → VERIFIED
Whiteboard: [fixed1.9.1b5] → [fixed1.9.1b99]
Crash Signature: [@ nsDisplayList::GetBottom]
You need to log in before you can comment on or make changes to this bug.