Bug 208527 - immediately crashes on startup
immediately crashes on startup
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tuxtype2 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steven Pritchard
Fedora Extras Quality Assurance
:
Depends On: 214048
Blocks: FE7Target
  Show dependency treegraph
 
Reported: 2006-09-29 03:10 EDT by Denis Leroy
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-27 20:05:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for freetype-2.2.1 (770 bytes, patch)
2006-11-04 22:53 EST, Trevin Beattie
no flags Details | Diff

  None (edit)
Description Denis Leroy 2006-09-29 03:10:39 EDT
on FC6t3, tuxtype immediately crashes on startup.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209043264 (LWP 26955)]
black_outline (t=0x80594c9 "Fish Cascade", font=0xa0b00e0, c=0x805fe28) at
alphabet.c:123
123             out = SDL_CreateRGBSurface(SDL_SWSURFACE, (tmp->w)+5,
(tmp->h)+5, 32, rmask, gmask, bmask, amask);
(gdb) bt
#0  black_outline (t=0x80594c9 "Fish Cascade", font=0xa0b00e0, c=0x805fe28) at
alphabet.c:123
#1  0x0804f51b in TitleScreen_load_menu () at titlescreen.c:75
#2  0x0804fdf4 in TitleScreen () at titlescreen.c:293
#3  0x0804e1b5 in main (argc=2, argv=0xbf888d84) at main.c:151
#4  0x00151f2c in __libc_start_main
Comment 1 Trevin Beattie 2006-10-01 18:00:42 EDT
This crash is due to improper (read: lack of) error checking after the call to
TTF_RenderText_Solid on the previous line.  It is returning NULL, causing the
program to crash when it tries to dereference a NULL pointer.

I added some debug code, which produced the following output:

TTF_RenderText_Solid failed at alphabet.c:127: Failed loading DPMSDisable:
/usr/lib64/libX11.so.6: undefined symbol: DPMSDisable
tuxtype2: alphabet.c:129: black_outline: Assertion `tmp' failed.
Aborted

I might make a difference that I upgraded SDL from 1.2.10 to 1.2.11, but I tried
downgrading SDL back to the version that came with FC6 (RC2) and it still
segfaulted.

What I can't figure out is why the "undefined symbol" error appears to be coming
from libX11.so.6, when it is actually defined in libXext.so.6.
Comment 2 Chris Hall 2006-11-04 19:55:06 EST
LoadImage: loading menu/regd.png
LoadImage: loading menu/reg0.png
LOADIMAGE: Done
LoadImage: loading menu/reg1.png
LOADIMAGE: Done
LoadImage: loading menu/reg2.png
LOADIMAGE: Done
LoadImage: loading menu/reg3.png
loading sprite menu/reg - contains 3 frames
LoadImage: loading tuxd.png
LoadImage: loading tux0.png
LOADIMAGE: Done
LoadImage: loading tux1.png
LOADIMAGE: Done
LoadImage: loading tux2.png
LOADIMAGE: Done
LoadImage: loading tux3.png
LOADIMAGE: Done
LoadImage: loading tux4.png
loading sprite tux - contains 4 frames
loading & parsing menu
black_outline of "Fish Cascade"
Segmentation fault

fc6 released version all default packages nvidia chipset amd processor nvidia
graphics
Comment 3 Steven Pritchard 2006-11-04 20:21:05 EST
FWIW, I haven't been ignoring this, but I'm not having any luck debugging the
problem.
Comment 4 Trevin Beattie 2006-11-04 21:48:29 EST
So far I've traced the error down to:
 TTF_RenderText_Solid at alphabet.c:123 ->
   TTF_RenderUNICODE_Solid at SDL_ttf.c:981 ->
     Find_Glyph at SDL_ttf.c:1089 ->
       Load_Glpyh at SDL_ttf.c:656 ->
         FT_Render_Glyph at SDL_ttf.c:503 ->
           FT_Render_Glpyh_Internal at (freetype) ftobjs.c:3298 ->
             ft_raster1_render at (freetype) ftobjs.c:3258
which returns error number 6 when called with the font "FreeSans Bold",
character ' ' (space).  This is a FreeType error for "invalid argument"; the SDL
error about DPMSDisable is apparently an old message that is not being properly
updated.

Digging a little deeper:
 ft_raster1_render at (freetype) ftobjs.c:3258 ->
   FT_ALLOC_MULT at (freetype) ftrend1.c:178 ->
     ft_mem_realloc at ftmemory.h:166 (macro) ->
       ft_mem_qrealloc at ftutil.c:101 ->
         error is set at ftutil.c:126
The error results from the fact that FT_ALLOC_MULT is called with a pitch and
height of 0.  Although a 0 parameter is perfectly valid in realloc(), apparently
the FreeType flavor doesn't like it.

Now I'm trying to figure out why the pitch and height of a space are 0, and
whether this is a problem with the font or with freetype.
Comment 5 Trevin Beattie 2006-11-04 22:20:50 EST
By including the following code near the top of SDL_ttf.c:

#undef __FTERRORS_H__
#define FT_ERROR_START_LIST {
#define FT_ERRORDEF(e,v,s) [e] = s,
#define FT_ERROR_ENDLIST };
static const char *ft_errstr[] =
#include FT_ERRORS_H

and placing a call to "TTF_SetError(ft_errstr[error]);" just before "return
error;" in Load_Glyph (2 spots: after FT_Load_Glyph and after FT_Render_Glyph),
I managed to get tuxtype2 to print the correct error message:

...
loading & parsing menu
black_outline of "Fish Cascade"
TTF_RenderText_Solid failed at alphabet.c:140: invalid argument

Of course, this only confirms what I've already tracked down; I still haven't
found out anything new.

It does seem like a good candidate for patching SDL_ttf, though.
Comment 6 Trevin Beattie 2006-11-04 22:50:11 EST
Found mention of a fix for this -- it appears to be a known freetype bug:

http://lists.gnu.org/archive/html/freetype/2006-07/msg00059.html

This refers to a CVS update, but doesn't say exactly what was fixed.  Browsing
through the freetype CVS tree, the following log message looked promising:

* src/base/ftutil.c (ft_mem_qrealloc): fix the function to accept 'item_size ==
0' as well, though this sounds weird, it can theoretically happen.
see bug #16669
Comment 7 Trevin Beattie 2006-11-04 22:53:20 EST
Created attachment 140376 [details]
Patch for freetype-2.2.1

This patch fixes freetype to allow zero-length memory allocation (for the space
character).  Once this is installed, tuxtype2 will run without further
modification.

Of course, it couldn't hurt to add some error checking code anyway so that
tuxtype exits gracefully rather than crashing when errors like this are
encountered.
Comment 8 Trevin Beattie 2006-11-04 23:06:01 EST
I've opened bug #214048 on freetype.
Comment 9 Denis Leroy 2006-11-05 05:11:34 EST
Trevin, nice work!
Comment 10 Steven Pritchard 2006-11-27 20:05:22 EST
This appears to be fixed on FC6 with the freetype 2.2.1-14.fc6 update.

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