Summary: | Crash in Font::glyphDataForCharacter when getting small caps data | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brett Wilson (Google) <brettw> | ||||
Component: | Text | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, mitz | ||||
Priority: | P1 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Brett Wilson (Google)
2008-06-13 18:22:44 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. (In reply to comment #2) > This should get the page cleared: I think it's a different kind of page :) Oh yeah. You're right... :) 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.
Comment on attachment 21842 [details]
Patch
r=me
Landed in <http://trac.webkit.org/changeset/34717>. Thanks mitz! |