Bug 447170

Summary: kcharselect locks with 100% CPU on Unicode #0x0F72
Product: [Fedora] Fedora Reporter: Roberto Ragusa <bugzillaredhat-56f0>
Component: kdeutilsAssignee: Than Ngo <than>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 8CC: kevin, ltinkl, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: F9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-20 09:58:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace output from kcharselect
none
valgrind kcharmapselect
none
valgrind gucharmap none

Description Roberto Ragusa 2008-05-18 13:56:52 UTC 
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.
Comment 1 Roberto Ragusa 2008-05-18 14:01:27 UTC 
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.
Comment 2 Roberto Ragusa 2008-05-18 14:04:18 UTC 
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().
Comment 3 Roberto Ragusa 2008-05-18 14:05:32 UTC 
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.
Comment 4 Kevin Kofler 2008-05-18 16:15:09 UTC 
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?
Comment 5 Lukáš Tinkl 2008-08-20 09:58:54 UTC 
I'd say fix this, the current version works fine
Comment 6 Kevin Kofler 2008-08-20 10:03:17 UTC 
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.