Hang/assertions with <select>, float, percentage margin

RESOLVED FIXED

Status

()

Core
Layout: Floats
P4
critical
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 2 bugs, {assertion, hang, testcase})

Trunk
x86
All
assertion, hang, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:Rs])

Attachments

(4 attachments)

(Reporter)

Description

11 years ago
I have a bunch of related testcases that hang and/or trigger one or more of these assertions:

###!!! ASSERTION: unexpected band data count: 'aBandData.mCount > 0', file /Users/jruderman/trunk/mozilla/layout/generic/nsSpaceManager.cpp, line 397

###!!! ASSERTION: If we asked for force-fit, it should have been placed: 'placed || !forceFit', file /Users/jruderman/trunk/mozilla/layout/generic/nsBlockReflowState.cpp, line 551

###!!! ASSERTION: aBandRect should be first rect within its band: '!aBandRect || aBandRect == mBandList.Head() || aBandRect->Prev()->mBottom != aBandRect->mBottom', file /Users/jruderman/trunk/mozilla/layout/generic/nsSpaceManager.h, line 493

This bug might be related to bug 383887.
(Reporter)

Comment 1

11 years ago
Created attachment 278170 [details]
testcase: hang
(Reporter)

Comment 2

11 years ago
Created attachment 278171 [details]
testcase: "unexpected band data count" assertion
(Reporter)

Updated

11 years ago
Blocks: 375980
(Reporter)

Updated

11 years ago
Severity: normal → critical
Flags: blocking1.9? → blocking1.9+
I posted a much-reduced version of this bug's testcases (specifically the <option style="margin: 100%;"> part) on bug 370872, because it triggers similar assertions to the second testcase in that bug, about unconstrained widths.

I'm pretty sure that bug 370872's high-percent-margin issue is (one of) the ultimate culprit(s) of this bug's problems, as well.
Depends on: 370872
OS: Mac OS X → All
Created attachment 283089 [details] [diff] [review]
patch v1 (add calls to NSCoordSaturatingAdd and NSCoordSaturatingSubtract)

GDB'd through a series of places where we need to call NSCoordSaturatingAdd / Subtract.

This patch fixes the hang (on the first testcase) and fixes all assertions mentioned in comment 1 (on both testcases).
Created attachment 283100 [details] [diff] [review]
patch v2 (also fixes some "metrics=xxxx,xxxx!" and "bad width" NOTREACHEDs)

Added a few more chunks to fix the following two things:

1. Some printf's like 

 nsBlockReflowContext: Block(option)(1)@0x8aebf54 metrics=xxxxx,yyyyy! 

where xxxxx is something close to, but not equal to, nscoord_MAX.


2. Some instances of this pair of messages:

###!!! ASSERTION: bad width: 'Not Reached', file /scratch/work/builds/trunk.07-10-01.09-47/mozilla/layout/generic/nsLineLayout.cpp, line 181
Block(select)(1)@0x8c7f098: Init: bad caller: width WAS 1073741584
Attachment #283100 - Flags: review?(dbaron)
For a bunch of these, it doesn't seem like either of the values being added should be nscoord_MAX.  e.g., for a computed width + a border+padding, I wouldn't expect either to be.

It might be useful to have comments that say which of the values can be nscoord_MAX when you're using these functions.  But in this case, I'm wondering whether the real problem is something else.  Or is there something I'm forgetting?
Yeah, I think you're right... We're probably working with  nscoord_MAX in some places as a result of bug 363858, when we should never have nscoord_MAX there in the first place.  (See some analysis in the duplicate bug 370872 comment 7, to see where the nscoord_MAX value originates from.)

I should probably wait to patch this until after bug 363858 is fixed, because that will probably take care of some or all of this bug's nscoord_MAX and/or hang issues.
Blocks: 363858
Attachment #283100 - Flags: review?(dbaron)
No longer blocks: 363858
Depends on: 363858
Whiteboard: [dbaron-1.9:Rs]
In my build with the patch for bug 363858 I don't see any hangs or asserts on the two testcases in this bug.
Is this still an issue?
(In reply to comment #8)
> In my build with the patch for bug 363858 I don't see any hangs or asserts on
> the two testcases in this bug.

Me neither, using current trunk.
(And I was able to reproduce those issues previously.)

Resolving as fixed, by 363858.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Flags: in-testsuite?
(Reporter)

Comment 11

10 years ago
Crashtests checked in.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.