WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
19542
Crash in Font::glyphDataForCharacter when getting small caps data
https://bugs.webkit.org/show_bug.cgi?id=19542
Summary
Crash in Font::glyphDataForCharacter when getting small caps data
Brett Wilson (Google)
Reported
2008-06-13 18:22:44 PDT
In Font::glyphDataForCharacter there is this code GlyphPageTreeNode* smallCapsNode = GlyphPageTreeNode::getRootChild(smallCapsFontData, pageNumber); const GlyphData& data = smallCapsNode->page()->glyphDataForCharacter(c); I got a crash report that shows page() returning NULL here, which caused a crash, although I do not have a repro. In GlyphPageTreeNode.h, it says: // Returns a page of glyphs (or NULL if there are no glyphs in this page's character range). GlyphPage* page() const { return m_page.get(); } So it looks like this Font.cpp code is wrong. Other callers of page() in this function NULL check it, but not this small caps case. It looks like we just need to add a check here.
Attachments
Patch
(1.84 KB, patch)
2008-06-19 11:01 PDT
,
Brett Wilson (Google)
hyatt
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1
2008-06-13 22:17:02 PDT
<
rdar://problem/6007976
>
Eric Seidel (no email)
Comment 2
2008-06-13 22:42:36 PDT
This should get the page cleared: <script> var ifr = document.createElement('iframe'); ifr.onload = function() { var win = ifr.contentWindow; // Remove, pow pageDestroyed. ifr.parentNode.removeChild(ifr); // Your Page is now cleared, do as you will to reproduce the rest of the bug! }; document.body.appendChild(ifr); </script> probably setting some font, or something to get it to relayout/resize a form control in smallcaps should trigger it.
mitz
Comment 3
2008-06-15 19:58:17 PDT
(In reply to
comment #2
)
> This should get the page cleared:
I think it's a different kind of page :)
Eric Seidel (no email)
Comment 4
2008-06-15 20:27:11 PDT
Oh yeah. You're right... :)
Brett Wilson (Google)
Comment 5
2008-06-19 11:01:05 PDT
Created
attachment 21842
[details]
Patch This patch just adds a NULL check for the page() of glyphs like the rest of the file. If this fails, it does the same thing it would do if the GlyphData in the page is NULL. I did not add a test. This patch is based on a crash report I saw. The stack is clear that the crash is dereferencing a NULL from the page() here, but I can not reproduce, even opening the page that triggered the crash report. I also tried to generate some small caps text in a funny language that wouldn't be in the font, but I could not trigger it. It is probably highly dependent on the WebKit port, OS, and installed fonts. If you have an idea for a test, I'll be happy to write it.
Dave Hyatt
Comment 6
2008-06-19 13:10:51 PDT
Comment on
attachment 21842
[details]
Patch r=me
mitz
Comment 7
2008-06-21 12:10:11 PDT
Landed in <
http://trac.webkit.org/changeset/34717
>.
Brett Wilson (Google)
Comment 8
2008-06-22 08:58:05 PDT
Thanks mitz!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug