Summary: | 100% CPU usage in XftCharIndex | ||
---|---|---|---|
Product: | xorg | Reporter: | Joachim Breitner <mail> |
Component: | Lib/Xft | Assignee: | Xorg Project Team <xorg-team> |
Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | critical | ||
Priority: | high | Keywords: | love |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | 2011BRB_Reviewed | ||
i915 platform: | i915 features: |
Description
Joachim Breitner
2011-03-05 22:06:25 UTC
Yeah, it looks like XftCharIndex does not handle errors well. We're stuck inside: while (font->hash_table[ent].ucs4 != ucs4) { if (font->hash_table[ent].ucs4 == (FcChar32) ~0) { if (!XftCharExists (dpy, pub, ucs4)) return 0; face = XftLockFace (pub); if (!face) return 0; font->hash_table[ent].ucs4 = ucs4; font->hash_table[ent].glyph = FcFreeTypeCharIndex (face, ucs4); XftUnlockFace (pub); break; } if (!offset) { offset = ucs4 % font->rehash_value; if (!offset) offset = 1; } ent = ent + offset; if (ent >= font->hash_value) ent -= font->hash_value; } Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.