This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 447170 - kcharselect locks with 100% CPU on Unicode #0x0F72
kcharselect locks with 100% CPU on Unicode #0x0F72
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kdeutils (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-18 09:56 EDT by Roberto Ragusa
Modified: 2008-08-20 06:03 EDT (History)
3 users (show)

See Also:
Fixed In Version: F9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-20 05:58:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Roberto Ragusa 2008-05-18 09:56:52 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.
Comment 1 Roberto Ragusa 2008-05-18 10:01:27 EDT
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 10:04:18 EDT
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 10:05:32 EDT
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 12:15:09 EDT
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 05:58:54 EDT
I'd say fix this, the current version works fine
Comment 6 Kevin Kofler 2008-08-20 06:03:17 EDT
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.