Here's some additional debugging information, indicating that failure is actually in libfreetype6. I've built libfreetype6 with DEB_BUILD_OPTIONS='nostrip' (if I add 'noopt', then segmentation fault no longer triggers) and got the following backtrace:
[EMAIL PROTECTED]:/tmp/ttf-fifthhorseman-dkg-handwriting-0.13# gdb /usr/bin/fontforge GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (no debugging symbols found) (gdb) set args dkg-handwriting.pe (gdb) run Starting program: /usr/bin/fontforge dkg-handwriting.pe (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Copyright (c) 2000-2008 by George Williams. Executable based on sources from 00:29 GMT 29-Apr-2008. Library based on sources from 20:49 GMT 30-Apr-2008. [New Thread 0xb71d06b0 (LWP 9620)] Generating Regular Font Generating Italic Font Generating Bold Font The stroke width is so big that the generated path may intersect itself in exclam FindMatchinHVEdge didn't FT_Open_Face: error=33 stream=0x100 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb71d06b0 (LWP 9620)] FT_Stream_Free (stream=0x100, external=0) at /tmp/freetype-2.3.7/freetype-2.3.7/src/base/ftobjs.c:189 189 FT_Memory memory = stream->memory; (gdb) bt #0 FT_Stream_Free (stream=0x100, external=0) at /tmp/freetype-2.3.7/freetype-2.3.7/src/base/ftobjs.c:189 #1 0xb75aa534 in FT_Open_Face (library=0x0, args=0xbfa46004, face_index=0, aface=0x9164e38) at /tmp/freetype-2.3.7/freetype-2.3.7/src/base/ftobjs.c:1836 #2 0xb75ab3be in FT_New_Memory_Face (library=0x0, file_base=0xbfa45dcc "\020\231l·à43·", file_size=26036, face_index=0, aface=0x9164e38) at /tmp/freetype-2.3.7/freetype-2.3.7/src/base/ftobjs.c:1160 #3 0xb7b903fb in __FreeTypeFontContext () from /usr/lib/fontforge/libfontforge.so.1 #4 0xb7b90a23 in _FreeTypeFontContext () from /usr/lib/fontforge/libfontforge.so.1 #5 0xb7b90a9c in FreeTypeFontContext () from /usr/lib/fontforge/libfontforge.so.1 #6 0xb7b50199 in BDFMakeGID () from /usr/lib/fontforge/libfontforge.so.1 #7 0xb7b502a1 in BDFMakeChar () from /usr/lib/fontforge/libfontforge.so.1 #8 0xb7b63a17 in PasteIntoFV () from /usr/lib/fontforge/libfontforge.so.1 #9 0xb7c59dd0 in ?? () from /usr/lib/fontforge/libfontforge.so.1 #10 0x090ac058 in ?? () #11 0x00000001 in ?? () #12 0x00000000 in ?? () The line 'FT_Open_Face: error=33 stream=0x100' is the debugging output I've added, it shows the values of error and stream after a call to FT_Stream_New() in FT_Open_Face(). The segfault is happening because call results in FT_Stream_Free call with stream set to 0x100 (clearly, a bogus address), where a check for stream validity 'if (stream)' passes, and attempt to dereference stream fails. When I build libfreetype6 without optimizations, the debugging output reads FT_Open_Face: error=33 stream=(nil) and so the problem is not triggered since stream is set to NULL. Not sure whether it's a subtle bug in libfreetype6 or a possible toolchain issue, further investigation is required (slightly tricky, since the FT_Stream_New function is heavily optimized when built with optimizations). Cheers. -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
