Closed Bug 463785 Opened 16 years ago Closed 16 years ago

Crash [@ nsHTMLReflowState::GetNearestContainingBlock] with postioning, -moz-column-count and binding

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1
Tracking Flags:
Tracking Status
status1.9.2 --- wanted
status1.9.1 --- wanted

People

(Reporter: martijn.martijn, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: crash, testcase, Whiteboard: [sg:dupe 411835])

Crash Data

Attachments

(4 files)

testcase
(deleted), application/xhtml+xml
Details
Frame dump
(deleted), text/html
Details
hack
(deleted), patch
Details | Diff | Splinter Review
Frame dump #2
(deleted), text/html
Details
Attached file testcase (deleted) —
See testcase, which crashes current trunk build after 100ms. It also crashes Firefox3, so marking security sensitive for now. http://crash-stats.mozilla.com/report/index/d85a17b8-aacd-11dd-89d6-001cc45a2ce4?p=1 0 xul.dll nsHTMLReflowState::GetNearestContainingBlock layout/generic/nsHTMLReflowState.cpp:704 1 xul.dll nsHTMLReflowState::InitAbsoluteConstraints layout/generic/nsHTMLReflowState.cpp:1117 2 xul.dll xul.dll@0x2d2e47 3 xul.dll nsHTMLReflowState::Init layout/generic/nsHTMLReflowState.cpp:288
Apparently, it doesn't crash online, but when viewing it in offline mode, it does crash. Probably the timer is too early fired online to get the crash.
Attached file Frame dump (deleted) —
Since we don't traverse continuations for subtrees we skip the (pink) overflow container, and thus miss the placeholder (0x190c940) to the out-of-flow we crash on (red).
Assignee: nobody → mats.palmgren
Attached patch hack (deleted) — — Splinter Review
FWIW, the "wip2" patch in bug 411835 also fixes it, though I haven't checked exactly why yet...
Blocks: 379349
Depends on: 411835
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.9.1?
The patch from bug 411835 fixes the testcase in this bug because it traverses next-in-flows for out-of-flows and thus we find the placeholder.
Attached file Frame dump #2 (deleted) —
The patch in this bug still crash with the testcase in bug 411835. When processing the next-in-flow (blue) of the top frame we unconditionally process OverflowContainers-list frames and we recurse into (yellow) and find the placeholder for (red) and add it to the destroy queue. Then we process the last next-in-flow (pink) and find the placeholder for (cyan) and add it to the destroy queue - we crash because (cyan) is an ancestor of (red) and thus (red) will be destroyed twice.
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Whiteboard: [partly fixed by 411835; has wip patch?]
FWIW, the patch in bug 411835 should fix this fully, but let's see if it passes review...
Whiteboard: [partly fixed by 411835; has wip patch?] → [fixed by 411835]
Priority: P2 → P3
Fixed by bug 411835 which includes the testcase for this bug (holding it until Firefox 3.0.x is fixed though). -> FIXED
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081208 Minefield/3.2a1pre
Status: RESOLVED → VERIFIED
Whiteboard: [fixed by 411835] → [sg:dupe 411835]
Bug 441835 was not fixed on 1.9.1 because of the regression in bug 468563 (currently still not fixed on trunk). Taking this bug off the blocker list, we won't hold the release for it.
Flags: blocking1.9.1+ → wanted1.9.1+
Crash Signature: [@ nsHTMLReflowState::GetNearestContainingBlock]
Landed the crash test: https://hg.mozilla.org/integration/mozilla-inbound/rev/8b5e4e71da99
Group: core-security
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: