Bug 208084

Summary: Foobillard won't start
Product: [Fedora] Fedora Reporter: Kjartan Maraas <kmaraas>
Component: foobillardAssignee: Miloslav Trmač <mitr>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: extras-qa, jantho, ondrej, trevin
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-05 09:03:51 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:
Bug Depends On: 208734    
Bug Blocks:    

Description Kjartan Maraas 2006-09-26 10:44:05 UTC
Description of problem:

I get this when I try to start foobillard here:

libGL warning: 3D driver claims to not support visual 0x4b
player_copy1
player_copy2
player_copy3
human player 1
player_copy3.5
player_copy4
player_copy1
player_copy2
player_copy3
human player 2
player_copy3.5
player_copy4
FT_Load_Glyph:error#6

This is on a Radeon Mobility based laptop. I have dri enabled in xorg.conf, and
other 3D using games like supertux work.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Trevin Beattie 2006-10-01 05:36:28 UTC
I've tracked this bug down to freetype-2.2.1 in Fedora Core 6.  The same version
of foobillard runs properly in Fedora Core 5 which has freetype-2.1.0.

The offending function is tt_cmap4_char_map_binary (in
freetype-2.2.1/src/sfnt/ttcmap.c).  Here is the backtrace:

#0  tt_cmap4_char_map_binary (cmap=0x7409a0, pcharcode=0x7fff42accf14, 
    next=0 '\0') at /usr/src/debug/freetype-2.2.1/src/sfnt/ttcmap.c:1191
#1  0x00002aaaaab18b34 in tt_cmap4_char_index (cmap=0x4, char_code=104)
    at /usr/src/debug/freetype-2.2.1/src/sfnt/ttcmap.c:1256
#2  0x000000000043efa7 in getStringGLListFT (str=0x798750 "hallo", 
    fontname=0x798850 "youregon.ttf", font_height=0.29999999999999999, 
    depth=0.0799999982, width=0x798958, height=<value optimized out>)
    at font.c:584
#3  0x000000000043d752 in textObj3D_new (str=0x442df7 "hallo", 
    fontname=0x442bed "youregon.ttf", height=<value optimized out>, 
    depth=0.0799999982, ppspline=<value optimized out>) at textobj.c:192
#4  0x0000000000411060 in main (argc=1, argv=<value optimized out>)
    at billard3d.c:5185

In frame 1 (tt_cmap4_char_index), there is a choice to call either
tt_cmap4_char_map_linear or tt_cmap4_char_map_binary depending on whether the
cmap is sorted.  If I call (from the debugger) tt_cmap4_char_map_linear, I get
the correct index of 70.  If I call tt_cmap4_char_map_binary using the same
parameters, I get an index of 57406, which is incorrect.

It appears that the problem starts around line 1100, when the OVERLAPPING flag
in the cmap is set.  The variable p is changed to "cmap->data + 14 + ( i - 1 ) *
2" (equal to cmap->data + 14 + ( mid - 1 ) * 2).  Since the character does not
occur in the previous segment, the loop breaks at line 1104.  mid and max are
still equal, so the block at 1119 is skipped; and mid and 'i' are still equal as
well, so the block at 1171 is skipped, which would have reset p to cmap->data +
14 + mid * 2.  I'm guessing that should have been the correct value of p.

It appears that this bug was fixed just yesterday:
http://cvs.savannah.gnu.org/viewcvs/freetype/freetype2/src/sfnt/ttcmap.c?r1=1.65&r2=1.66

I patched the file, rebuilt and installed freetype, and now foobillard runs.


Comment 2 Miloslav Trmač 2006-10-01 14:18:46 UTC
Thanks for debugging this!

Comment 3 Kjartan Maraas 2006-10-17 10:20:50 UTC
Would it be possible to get this fix into FC6? Are we sure foobillard is the
only app that breaks from this?

Comment 4 Kjartan Maraas 2006-10-17 10:22:06 UTC
Moving this to fedora core/freetype

Comment 5 Miloslav Trmač 2006-10-17 10:24:39 UTC
#208734, which blocks this bug, is already filed against freetype.

Comment 6 Miloslav Trmač 2006-12-05 09:03:51 UTC
Fixed in freetype-2.2.1-16.fc6.

Comment 7 Ondrej Svetlik 2006-12-05 09:11:59 UTC
I've tested this yesterday on x86_64 and it works - thanks a lot.