Red Hat Bugzilla – Bug 208084
Foobillard won't start
Last modified: 2007-11-30 17:11:44 EST
Description of problem:
I get this when I try to start foobillard here:
libGL warning: 3D driver claims to not support visual 0x4b
human player 1
human player 2
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):
Steps to Reproduce:
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)
#2 0x000000000043efa7 in getStringGLListFT (str=0x798750 "hallo",
fontname=0x798850 "youregon.ttf", font_height=0.29999999999999999,
depth=0.0799999982, width=0x798958, height=<value optimized out>)
#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>)
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:
I patched the file, rebuilt and installed freetype, and now foobillard runs.
Thanks for debugging this!
Would it be possible to get this fix into FC6? Are we sure foobillard is the
only app that breaks from this?
Moving this to fedora core/freetype
#208734, which blocks this bug, is already filed against freetype.
Fixed in freetype-2.2.1-16.fc6.
I've tested this yesterday on x86_64 and it works - thanks a lot.