Bug 447170 - kcharselect locks with 100% CPU on Unicode #0x0F72
Summary: kcharselect locks with 100% CPU on Unicode #0x0F72
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kdeutils
Version: 8
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-18 13:56 UTC by Roberto Ragusa
Modified: 2008-08-20 10:03 UTC (History)
3 users (show)

Fixed In Version: F9
Clone Of:
Environment:
Last Closed: 2008-08-20 09:58:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
strace output from kcharselect (238.99 KB, text/plain)
2008-05-18 14:01 UTC, Roberto Ragusa
no flags Details
valgrind kcharmapselect (7.93 KB, text/plain)
2008-05-18 14:04 UTC, Roberto Ragusa
no flags Details
valgrind gucharmap (5.42 KB, text/plain)
2008-05-18 14:05 UTC, Roberto Ragusa
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.