Closed
Bug 444027
Opened 16 years ago
Closed 15 years ago
Crash with iExploder test 40129979 [@ BuildTextRunsScanner::FindBoundaries]
Categories
(Core :: Layout: Block and Inline, defect, P3)
Core
Layout: Block and Inline
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: MatsPalmgren_bugz, Assigned: MatsPalmgren_bugz)
References
Details
(6 keywords)
Crash Data
Attachments
(2 files)
37.89 KB,
text/html
|
Details | |
11.00 KB,
patch
|
roc
:
review+
roc
:
superreview+
dbaron
:
approval1.9.1+
dveditz
:
approval1.9.0.9+
|
Details | Diff | Splinter Review |
Followup from bug 421671. Both testcases in bug 421671 still generates many assertions and finally aborts at "running past end": http://hg.mozilla.org/mozilla-central/index.cgi/file/ee8961927fb4/layout/generic/nsLineBox.h#l611 Here's an up-to-date list of assertions on Linux: Doing nscoord addition with values > nscoord_MAX: 'a < nscoord_MAX && b < nscoord_MAX', file ../../dist/include/gfx/nsCoord.h, line 150 comparing iterators over different lists: 'mListLink == aOther.mListLink', layout/base/../generic/nsLineBox.h, line 690 no unconstrained widths should be present anymore: 'NS_UNCONSTRAINEDSIZE != aReflowState.ComputedWidth()', layout/generic/nsBlockReflowState.cpp, line 113 should no longer be using unconstrained sizes: 'aRightEdge != NS_UNCONSTRAINEDSIZE', layout/generic/nsLineLayout.cpp, line 411 should no longer be using unconstrained widths: 'aWidth != NS_UNCONSTRAINEDSIZE', layout/generic/nsLineLayout.cpp, line 178 should no longer use available widths: 'availableWidth != NS_UNCONSTRAINEDSIZE', layout/generic/nsInlineFrame.cpp, line 428 shouldn't have unconstrained widths anymore: 'NS_UNCONSTRAINEDSIZE != aReflowState.availableWidth', layout/generic/nsLineLayout.cpp, line 1087 shouldn't have unconstrained widths anymore: 'psd->mRightEdge != NS_UNCONSTRAINEDSIZE', layout/generic/nsLineLayout.cpp, line 2404 shouldn't have unconstrained widths anymore: 'psd->mRightEdge != NS_UNCONSTRAINEDSIZE', layout/generic/nsLineLayout.cpp, line 782 shouldn't use unconstrained widths anymore: '(mFrameType == NS_CSS_FRAME_TYPE_INLINE && !frame->IsFrameOfType(nsIFrame::eReplaced)) || frame->GetType() == nsGkAtoms::textFrame || mComputedWidth != NS_UNCONSTRAINEDSIZE', layout/generic/nsHTMLReflowState.cpp, line 315 shouldn't use unconstrained widths anymore: 'availableWidth != NS_UNCONSTRAINEDSIZE', layout/generic/nsHTMLReflowState.cpp, line 294 this shouldn't happen anymore: 'NS_UNCONSTRAINEDSIZE != aComputedWidth && NS_UNCONSTRAINEDSIZE != aAvailWidth', layout/generic/nsHTMLReflowState.cpp, line 1926 unconstrained available width in reflow: 'NS_UNCONSTRAINEDSIZE != aAvailSpace.width', layout/tables/nsTableRowFrame.cpp, line 74 unconstrained widths no longer supported: 'aContainingBlockWidth != NS_UNCONSTRAINEDSIZE', layout/base/nsLayoutUtils.cpp, line 1879 bad width: 'Not Reached', layout/generic/nsLineLayout.cpp, line 181 comparing iterators over different lists: 'mListLink == aOther.mListLink', layout/base/../generic/nsLineBox.h, line 690
Comment 1•16 years ago
|
||
"running past end" is really bad.
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
Updated•16 years ago
|
Flags: blocking1.9.0.1? → blocking1.9.0.2?
Comment 2•16 years ago
|
||
Not blocking, but wanted.
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.2-
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Assignee | ||
Comment 3•16 years ago
|
||
I have a fix for this in my tree...
Assignee: nobody → mats.palmgren
Whiteboard: [has unposted fix in Mats's tree]
Mats, any chance you could post that fix? Or are you saying that it's fixed by the fix for some other bug that you have in your tree and you don't know which?
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Assignee | ||
Comment 5•15 years ago
|
||
Assignee | ||
Comment 6•15 years ago
|
||
InlineIntrinsicWidthData::line needs to be updated if the continuation is within a new line container. This patch makes us trigger: ASSERTION: Wrong line container hint: '!aForFrame || aLineContainer == FindLineContainer(aForFrame)' http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsTextFrameThebes.cpp?mark=969#959 for floating first-letter frames because nsLineLayout's line container: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsLineLayout.h?mark=366#361 disagree with FindLineContainer(): http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsTextFrameThebes.cpp#776 I muted that case for now, I think we can fix it separately.
Attachment #361176 -
Flags: superreview?(roc)
Attachment #361176 -
Flags: review?(roc)
Assignee | ||
Updated•15 years ago
|
Whiteboard: [has unposted fix in Mats's tree]
Attachment #361176 -
Flags: superreview?(roc)
Attachment #361176 -
Flags: superreview+
Attachment #361176 -
Flags: review?(roc)
Attachment #361176 -
Flags: review+
Assignee | ||
Comment 7•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/a303089722f1 (holding the crashtests until 1.9.1/1.9.0 is fixed) -> FIXED
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Comment 8•15 years ago
|
||
(Filed follow-up bug 477781 on the line container disagreement)
Comment 9•15 years ago
|
||
This bug is public, so I see no need to hold the crashtests.
Assignee | ||
Comment 10•15 years ago
|
||
Ok, I thought bug 421671 (where the tests are) was hidden... anyway, the iExploder bugs probably doesn't need to be hidden at all since the test suite is public. FWIW, I have now run iExploder test 1 to 30000 on MacOSX and the only crash I encountered was bug 477775. Pushed the crashtest: http://hg.mozilla.org/mozilla-central/rev/4233c31e67d8
Flags: in-testsuite? → in-testsuite+
Assignee | ||
Updated•15 years ago
|
Attachment #361176 -
Flags: approval1.9.1?
Attachment #361176 -
Flags: approval1.9.0.8?
Assignee | ||
Comment 11•15 years ago
|
||
Comment on attachment 361176 [details] [diff] [review] Patch rev. 1 This fixes a nasty crash. Asking for approval together with bug 477928.
Updated•15 years ago
|
Flags: blocking1.9.0.8?
Updated•15 years ago
|
Flags: blocking1.9.0.8? → blocking1.9.0.8+
Updated•15 years ago
|
Attachment #361176 -
Flags: approval1.9.0.8? → approval1.9.0.8+
Comment 12•15 years ago
|
||
Comment on attachment 361176 [details] [diff] [review] Patch rev. 1 Approved for 1.8.1.21, a=dveditz for release-drivers
Comment 13•15 years ago
|
||
sorry, wrong paste buffer Approved for 1.9.0.8, a=dveditz for release-drivers (as the flag says).
Comment on attachment 361176 [details] [diff] [review] Patch rev. 1 a1.9.1=dbaron, but it must land along with bug 477928
Attachment #361176 -
Flags: approval1.9.1? → approval1.9.1+
Assignee | ||
Comment 15•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8fed6a0625ce http://hg.mozilla.org/releases/mozilla-1.9.1/rev/39460eaf5d06 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ce70e94d5e1c
Keywords: fixed1.9.1
Assignee | ||
Comment 16•15 years ago
|
||
mozilla/layout/generic/nsBlockFrame.cpp 3.960 mozilla/layout/generic/nsIFrame.h 3.405 mozilla/layout/generic/nsLineBox.h 1.98 mozilla/layout/generic/nsTextFrameThebes.cpp 3.188 mozilla/layout/generic/crashtests/421671.html 1.1 mozilla/layout/generic/crashtests/crashtests.list 1.122
Keywords: fixed1.9.0.8
Comment 17•15 years ago
|
||
Verified with 1.9.0.8 using crashtest checked in.
Keywords: fixed1.9.0.8 → verified1.9.0.8
Updated•15 years ago
|
Flags: wanted1.8.1.x-
Comment 18•15 years ago
|
||
verified FIXED on builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090428 Minefield/3.6a1pre ID:20090428031037 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090427 Shiretoko/3.5b5pre ID:20090427031112
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Updated•13 years ago
|
Crash Signature: [@ BuildTextRunsScanner::FindBoundaries]
You need to log in
before you can comment on or make changes to this bug.
Description
•