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
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.
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
FWIW, I haven't been ignoring this, but I'm not having any luck debugging the problem.
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.
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.
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
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.
I've opened bug #214048 on freetype.
Trevin, nice work!
This appears to be fixed on FC6 with the freetype 2.2.1-14.fc6 update.