Red Hat Bugzilla – Bug 447170
kcharselect locks with 100% CPU on Unicode #0x0F72
Last modified: 2008-08-20 06:03:17 EDT
Description of problem: kcharselect locks with 100% CPU when trying to show a specific character (0F72;TIBETAN VOWEL SIGN I). The process must be killed. Version-Release number of selected component (if applicable): $ rpm -qf `which kcharselect` kdeutils-3.5.9-1.fc8 $ rpm -q freetype freetype-2.3.5-3.fc8 $ rpm -q libXft libXft-2.1.12-3.fc8 How reproducible: Always. Steps to Reproduce: 1. Run kcharselect 2. Write "15" in the table selection 3. no step 3, kcharselect is now 100% busy Actual results: 100% CPU burning when attempting to draw the 0f72 char. Expected results: Display that char and all successive ones. Additional info: If you go to an "empty" table (e.g. 45) and then 15 it is easier to understand on what char the process locks. The problem appears to be related to the font jomolhari-fonts-0.003-4.fc8 /usr/share/fonts/jomolhari/Jomolhari-alpha3c-0605331.ttf Disabling the font with chmod 000 /usr/share/fonts/jomolhari/Jomolhari-alpha3c-0605331.ttf solves the problem. The font itself could be corrupted/invalid, but it appears to work with gucharmap or fontforge. And invalid fonts should not cause DoS, so opening the bug to kcharselect.
Created attachment 305847 [details] strace output from kcharselect Adding strace output, showing that after opening /usr/share/fonts/jomolhari/Jomolhari-alpha3c-0605331.ttf the process enters an infinite loop, after some memory allocations.
Created attachment 305849 [details] valgrind kcharmapselect Kcharselect running under valgrind, up to getting stuck at 100% CPU. Note suspicious stuff about FT_Outline_Get_Orientation().
Created attachment 305850 [details] valgrind gucharmap Gucharmap running under valgrind, successfully. The suspicious stuff about FT_Outline_Get_Orientation() is present here too, but everything appears to work properly.
Yes, the KDE 3 kcharmap chokes on Tibetan, maybe a Qt 3 bug. This has been fixed in Qt/KDE 4, I tested the F9 version and it doesn't crash on these characters anymore (at least in QEMU). Shall we try to patch Qt/KDE 3 or shall we just close this as fixed in Fedora 9?
I'd say fix this, the current version works fine
Well, qt3 in F9 probably still has that bug, there's just no KCharSelect to trigger it. Still, I guess it can stay closed as long as there's no actual app triggering it.