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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Martijn Wargers (dead)]

Attachment: testcase

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

Comment 1

[Martijn Wargers (dead)]

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.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Frame dump

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).

Comment 3

[Mats Palmgren (inactive)]

Attachment: hack

Comment 4

[Mats Palmgren (inactive)]

FWIW, the "wip2" patch in bug 411835 also fixes it, though I haven't checked
exactly why yet...

Comment 5

[Mats Palmgren (inactive)]

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.

Comment 6

[Mats Palmgren (inactive)]

Attachment: Frame dump #2

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.

Comment 7

[Mats Palmgren (inactive)]

FWIW, the patch in bug 411835 should fix this fully, but let's see if it
passes review...

Comment 8

[Mats Palmgren (inactive)]

Fixed by bug 411835 which includes the testcase for this bug (holding it
until Firefox 3.0.x is fixed though).

-> FIXED

Comment 9

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081208 Minefield/3.2a1pre

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 11

[Mats Palmgren (inactive)]

Landed the crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b5e4e71da99

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8b5e4e71da99