Closed Bug 375772 Opened 17 years ago Closed 17 years ago

Crash loading a certain page as UTF8

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9alpha6

People

(Reporter: bzbarsky, Assigned: karlt)

References

Details

(Keywords: crash, regression)

Attachments

(6 files)

STEPS TO REPRODUCE:

1)  Load the attached page (coming up).
2)  Make sure that it's being rendered as UTF8 (View menu, etc).
3)  Scroll to the bottom.

ACTUAL RESULTS: Crash

EXPECTED RESULTS:  Not crash

ADDITIONAL INFORMATION:

The page originally comes from http://mxr.mozilla.org/l10n-mozilla1.8/search?string=findField.tooltip

The talkback incident for me first hitting this is TB30683643

The crash is caused by:

** ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0)
aborting...

glyphs->num_glyphs is 0.

The top of the stack is:

#5  0x001947cd in pango_shape (text=0x0, length=0, analysis=0x6, glyphs=0x90e2ad0)
    at shape.c:75
#6  0xb5af1a12 in FontSelector::AppendNextSegment (this=0xbfffbca0, aFont=0x8fceff8, 
    aUTF8Length=1, aGlyphs=0x90e2ad0, aGotGlyphs=0)
    at ../../../../mozilla/gfx/thebes/src/gfxPangoFonts.cpp:1273
#7  0xb5af1824 in FontSelector::InitSegments (this=0xbfffbca0, aOffset=0, aLength=91, 
    aFontIndex=0) at ../../../../mozilla/gfx/thebes/src/gfxPangoFonts.cpp:1377
#8  0xb5af0b83 in FontSelector::Run (this=0xbfffbca0)
    at ../../../../mozilla/gfx/thebes/src/gfxPangoFonts.cpp:1226

In frame 7:

(gdb) list
1372                            }
1373                        }
1374
1375                        if (i != 0) {
1376                            // found glyphs
1377                            AppendNextSegment(font, offset - (aOffset + skipLength),
1378                                              glyphString, PR_FALSE);
1379                        }
1380
1381                        // missing glyphs
(gdb) p i
$19 = 28
(gdb) p glyphString->num_glyphs
$20 = 0
(gdb) p num_glyphs
$21 = 49

I'm not sure how to reconcile those last two numbers, to be honest...
Flags: blocking1.9?
Attached file Testcase
I can't reproduce a crash here, though the testcase asserts quite a lot. All the assertions seem to be coming from this line (the pa-IN line from the original)
I get neither minimal asserts, nor the abort with that minimized testcase.  I can try minimizing this, I guess.
This bug looks similar to bug 370414.

I can't reproduce the crash by selecting View->C.E.->UTF-8, but I do crash
on the first testcase when selecting UTF-16.  Before the crash I see:

###!!! ASSERTION: got a high Surrogate but no low surrogate: 'Error', file ../../../dist/include/string/nsUTF8Utils.h, line 690
###!!! ASSERTION: got a high Surrogate but no low surrogate: 'Error', file ../../../dist/include/string/nsUTF8Utils.h, line 690
###!!! ASSERTION: got a high Surrogate but no low surrogate: 'Error', file ../../../dist/include/string/nsUTF8Utils.h, line 690
###!!! ASSERTION: Didn't resolve all characters: 'utf16Offset == aTextRun->GetLength()', file gfxPangoFonts.cpp, line 1545

I'm not sure if the UTF-16 crash is the same, or if it's a separate bug.
(FWIW, I can't make the second testcase crash)
This crashes for me.
For what it's worth, I also crash with this exact stack at http://en.wikipedia.org/wiki/Trisagion if I scroll down a few pages.  I hate it when trunk really is a minefield...
So at this point I can no longer read e-mail with trunk because something in my inbox is triggering this bug, so as soon as I load the inbox I crash...

Are we seriously planning to ship 1.9a4 with this?
(In reply to comment #5)
> Created an attachment (id=260206) [details]

I can't reproduce.  Can you attach the resulting file when you Quit immediately after running something like the following?

FC_DEBUG=1 minefield test.html > minefield-375772.fc_debug

Also what version of pango are you using?
> I can't reproduce.

Might depend on the fonts you have installed, dunno...

> Can you attach the resulting file

Attached.

> Also what version of pango are you using?

The X client is using either pango 1.6.0 or pango 1.8.1 -- both crash.  The X server is on the machine with pango 1.8.1.
By explicitly specifying Luxi Sans in the CSS and including the following in ~/.fonts.conf, I managed to get some interesting asserts.

 <match target="pattern" >
  <test name="lang" >
   <string>el</string>
  </test>
  <edit mode="prepend" binding="strong" name="family" >
   <string>Console</string>
  </edit>
 </match>

(Console is console8x16 from Konsole.)

(Gecko:18580): Pango-WARNING **: shape engine failure, expect ugly output. the offending font is 'Luxi Sans 12'
###!!! ASSERTION: Someone has added too many glyphs!: 'Error', file /home/karl/moz/mozilla/gfx/thebes/src/gfxPangoFonts.cpp, line 1030
###!!! ASSERTION: Cannot draw partial ligatures without a dirty rect: 'aDirtyRect', file /home/karl/moz/mozilla/gfx/thebes/src/gfxFont.cpp, line 897
###!!! ASSERTION: Cannot draw partial ligatures without a dirty rect: 'aDirtyRect', file /home/karl/moz/mozilla/gfx/thebes/src/gfxFont.cpp, line 897

Hopefully its related...

(You may be able to read your email if you install dejavu or Times New Romain from corefonts.)
Does applying the last patch in bug 357637 have any effect here? (attachment 262225 [details] [diff] [review])
> You may be able to read your email if you install dejavu or Times New Romain

I have Times New Roman, if that's what you meant.  Apparently it doesn't have some characters in question?

> Does applying the last patch in bug 357637 have any effect here? 

Yes.  It makes the crashes on the original and minimized testcases I posted in this bug and on the wikipedia URL I cited disappear.  ;)
But email still crashes?
Depends on: 357637
No idea.  I don't have a mail account set up in my devel profile, and I wouldn't trust that build with my mail anyway....
Here is a one line patch that fixes the problems reported in comment #10.

The problem appears to be in FontSelector::InitSegments.
Attachment 262225 [details] [diff] in bug 357637 is a fairly large patch that rewrites this method, but something seems to be holding up its review.

(Sorry to request review from you roc when your travels are keeping you busy but it looks like this is your code that is being modified.)
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Attachment #263422 - Flags: superreview?(roc)
Attachment #263422 - Flags: review?(roc)
Attachment #263422 - Flags: superreview?(roc)
Attachment #263422 - Flags: superreview+
Attachment #263422 - Flags: review?(roc)
Attachment #263422 - Flags: review+
Flags: blocking1.9? → blocking1.9+
Target Milestone: --- → mozilla1.9alpha6
Should now be fixed as attachment 263898 [details] [diff] [review] in bug 357637 has been checked in.
It fixes the problems reported in comment #10.
Can you confirm that it is fixed for the original testcases?
Looks good, yes.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: