[Webkit-unassigned] [Bug 16054] Crash when GlyphPage::fill is called with more than 256 bytes of data
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Nov 19 17:57:47 PST 2007
http://bugs.webkit.org/show_bug.cgi?id=16054
alp at atoker.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
------- Comment #3 from alp at atoker.com 2007-11-19 17:57 PDT -------
(In reply to comment #1)
> Created an attachment (id=17405)
--> (http://bugs.webkit.org/attachment.cgi?id=17405&action=view) [edit]
> not a real fix
>
> I am not sure if this is the right approach.. in fact, i am pretty sure that it
> isn't.
>
This is straight from the Windows port
(WebCore/platform/win/GlyphPageTreeNodeWin.cpp):
bool GlyphPage::fill(UChar* buffer, unsigned bufferLength, const FontData*
fontData)
{
// The bufferLength will be greater than the glyph page size if the buffer
has Unicode supplementary characters.
// We won't support this for now.
if (bufferLength > GlyphPage::size)
return false;
bool haveGlyphs = false;
CGGlyph localGlyphBuffer[GlyphPage::size];
wkGetGlyphs(fontData->platformData().cgFont(), buffer, localGlyphBuffer,
bufferLength);
for (unsigned i = 0; i < GlyphPage::size; i++) {
Glyph glyph = localGlyphBuffer[i];
if (!glyph)
setGlyphDataForIndex(i, 0, 0);
else {
setGlyphDataForIndex(i, glyph, fontData);
haveGlyphs = true;
}
}
return haveGlyphs;
}
Looks like this strategy is just fine for now, and fixes a real crasher bug.
Nice catch!
Looking at this line from Win:
for (unsigned i = 0; i < GlyphPage::size; i++)
We do this instead:
for (unsigned i = 0; i < bufferLength; i++)
Both yield the same result AFAICT. I wonder which is more correct.
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list