110 bytes, text/html
2.68 KB, patch
|Details | Diff | Splinter Review|
2.69 KB, patch
|Details | Diff | Splinter Review|
I'm hitting this a lot. Regression from bug 481948?
###!!! ASSERTION: character/glyph clump contains no glyphs!: 'glyphStart < glyphEnd', file /Users/jruderman/central/gfx/thebes/src/gfxAtsuiFonts.cpp, line 1151 ###!!! ASSERTION: character/glyph contains no characters!: 'charStart != charEnd', file /Users/jruderman/central/gfx/thebes/src/gfxAtsuiFonts.cpp, line 1152 ###!!! ASSERTION: aPos out of range: '0 <= aPos && aPos < mCharacterCount', file ../../../dist/include/thebes/gfxFont.h, line 857 ###!!! ASSERTION: Index out of range: 'aIndex < mCharacterCount', file /Users/jruderman/central/gfx/thebes/src/gfxFont.cpp, line 2295 firefox-bin(25991,0xa04ca720) malloc: *** error for object 0x77180000: pointer being freed was not allocated many of ###!!! ASSERTION: aPos out of range: '0 <= aPos && aPos < mCharacterCount', file ../../../dist/include/thebes/gfxFont.h, line 857 crash [@ gfxTextRun::CompressedGlyph::IsClusterStart] touching 0x1ee00000
I see this bug on my bottom mini, but not on my macbook pro. Odd, since they're both running Leopard.
Yes, this will surely be a result of bug 481948. (In reply to comment #2) > I see this bug on my bottom mini, but not on my macbook pro. Odd, since > they're both running Leopard. Are you running the same binary on both, or building separately on each? I notice the problem is in the (rewrite of the) ATSUI text path, so I'm guessing your MBPro is using CoreText instead. So either a build difference (10.4u vs 10.5 SDK, which determines whether the CoreText code is built), or a profile difference.
Building separately. It will be a few weeks before I can see which SDK each computer uses.
Confirmed that I get this failure with ATSUI and not with CoreText (with the same build, 10.5 SDK, using the gfx.force_atsui_text pref to control which path is used).
The particular case that triggered the failure is an isolated low surrogate in a right-to-left text run. The clustering code has a special case for low surrogates in RTL text in order to improve cursor/selection behavior (to associate them with the proper high surrogate), but we shouldn't do this if the low surrogate was unpaired.
Assignee: nobody → jfkthame
Attachment #375261 - Flags: review?(roc)
Comment on attachment 375261 [details] [diff] [review] fix handling of unpaired low surrogate in RTL text add a line break so the line isn't too long
Attachment #375261 - Flags: review?(roc) → review+
Should add the test as a crashtest too.
Whiteboard: [needs landing]
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
Whiteboard: [needs 191 landing] → [needs 191 approval]
Code patch is exactly the same for trunk and 1.9.1 (once 481948 is applied there), but in order to land cleanly the crashtest list is updated. This should land on branch at the same time as bug 481948, otherwise we will have a regression there.
Previous version of the 1.9.1 patch was incomplete (failed to add the test file). Sorry about the bug-spam. :(
Comment on attachment 376486 [details] [diff] [review] patch for 1.9.1, corrected [Checkin: Comment 15] a191=beltzner
Attachment #376486 - Flags: approval1.9.1? → approval1.9.1+
NB: for 1.9.1, this should land on top of the patch for bug 481948, and be pushed together.
Whiteboard: [needs 191 approval] → [needs 191 landing]
Whiteboard: [needs 191 landing] → [needs 1.9.1 landing: see comment 14]
Attachment #375349 - Attachment description: broken the long line, added crashtest → broken the long line, added crashtest [Checkin: Comment 10]
Comment on attachment 376486 [details] [diff] [review] patch for 1.9.1, corrected [Checkin: Comment 15] http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2a4c9e79d7b8
Attachment #376486 - Attachment description: patch for 1.9.1, corrected → patch for 1.9.1, corrected [Checkin: Comment 15]
You need to log in before you can comment on or make changes to this bug.