Closed
Bug 404624
Opened 17 years ago
Closed 17 years ago
ASSERTION: Invalid offset with ::first-letter and letter-spacing
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
People
(Reporter: martijn.martijn, Assigned: roc)
Details
(Keywords: assertion, testcase)
Attachments
(2 files, 1 obsolete file)
120 bytes,
text/html
|
Details | |
9.86 KB,
patch
|
smontagu
:
review+
|
Details | Diff | Splinter Review |
See testcase, I get this assertion in current debug trunk build: ###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount', file c:/m ozilla-build/mozilla/gfx/thebes/src/gfxSkipChars.cpp, line 92 ###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount', file c:/m ozilla-build/mozilla/gfx/thebes/src/gfxSkipChars.cpp, line 92
Assignee | ||
Comment 1•17 years ago
|
||
This should get fixed, memory errors can develop
Assignee: nobody → roc
Flags: blocking1.9?
Priority: -- → P3
Updated•17 years ago
|
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Comment 2•17 years ago
|
||
The problem here is that we're passing too-long a length to PropertyProvider when we construct it. The textrun may not map all the content in the flow chain, represented by GetInFlowContentLength(), so we get these errors when we check IsInBounds. My solution here is to allow PR_INT32_MAX to be used as the content length to indicate we don't really know or care what it is. Most PropertyProvider methods don't actually need it except for bounds checking.
Attachment #290494 -
Flags: review?(smontagu)
Assignee | ||
Updated•17 years ago
|
Whiteboard: [needs review]
Comment 3•17 years ago
|
||
Why don't we need to check for PR_INT32_MAX whenever we call PropertyProvider.GetOriginalLength(), e.g. nsTextFrame::PaintTextSelectionDecorations and elsewhere?
Assignee | ||
Comment 4•17 years ago
|
||
Yeah, I should do that. Sorry, I'll post a new patch.
Assignee | ||
Comment 5•17 years ago
|
||
Updated patch with that. The callers of GetOriginalLength construct their own PropertyProvider so it's pretty easy to see that assert won't fire.
Attachment #290494 -
Attachment is obsolete: true
Attachment #290647 -
Flags: review?(smontagu)
Attachment #290494 -
Flags: review?(smontagu)
Updated•17 years ago
|
Attachment #290647 -
Flags: review?(smontagu) → review+
Assignee | ||
Comment 6•17 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: [needs review]
Assignee | ||
Comment 7•17 years ago
|
||
I just backed this out because I think it may be causing a mochitest failure. (It had been backed out and relanded due to suspicious Tp.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 8•17 years ago
|
||
Tinderbox seems to show that the mochitest failure went away before I backed this out, so I relanded it.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•17 years ago
|
||
With my updated debug build, I don't see the assertion anymore, so verified fixed.
Status: RESOLVED → VERIFIED
Comment 10•6 years ago
|
||
Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4477e9235df0 Add crashtest. r=mats
Updated•6 years ago
|
Flags: in-testsuite+
Comment 11•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4477e9235df0
You need to log in
before you can comment on or make changes to this bug.
Description
•