290 bytes, application/xhtml+xml
584 bytes, application/xhtml+xml
14.71 KB, patch
|Details | Diff | Splinter Review|
18.09 KB, patch
|Details | Diff | Splinter Review|
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.
11 years ago
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
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
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.
Priority: -- → P4
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
Crashtests checked in.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.