[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