Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-09 Thread Werner LEMBERG
> Sorry, I don't have this font (on Microsoft Windows XP for Japanese
> market). Could you tell me which Microsoft products have it?

You need the file `ie_zhc.exe' which can be unpacked with `cabextract'.

  
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=DEB6731A-CA36-47A3-B4A0-2A1D19EEFA05&%3Bdisplaylang=en


Werner

___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-09 Thread mpsuzuki
On Sat, 8 Jan 2011 17:44:23 -0800
"Tom Bishop, Wenlin Institute"  wrote:

>On Jan 1, 2011, at 11:31 PM, Werner LEMBERG wrote:
>
>...
>> Which font is it?  Maybe I already have it.  Otherwise, please send me
>> the font privately for further investigation.
>
>I've reproduced the crash with a different font: mssong.ttf, glyph number 
>1006. This font is available for free from Microsoft.

Sorry, I don't have this font (on Microsoft Windows XP
for Japanese market). Could you tell me which Microsoft
products have it?

Regards,
mpsuzuki

___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-09 Thread Tom Bishop, Wenlin Institute

On Jan 9, 2011, at 12:07 AM, Werner LEMBERG wrote:
> ...
> This won't compile.  You need -DFT2_BUILD_LIBRARY also.

I forgot to mention that I had set up FreeType 2.4.4 as follows:

Ran "./configure", "make", and "sudo make install".

Added this line to ft2build.h:
#define FT2_BUILD_LIBRARY

> Adding FT2_DEBUG=any:5 to the environment, I get the same output as
> you but complete, without crash.

And that's on Linux, right? I imagine it would crash for anyone using MinGW GCC 
4.5 on Windows XP. I have confirmed that on a second machine.

>> The output is shown below. The stuff at the end about "# of
>> contours: -1" and "Glyph 22971" is mysterious.
> 
> Not at all: -1 for the number of contours specifies that it is a
> composite glyph.  What follows are the subglyphs.

So that's probably not related to the problem. I think the other font for which 
the crash occurred does not have composite glyphs.

> Using valgrind, I get two warnings specific to the demo program:
> 
>   Use of uninitialised value of size 4
>  at 0x808F02F: __longjmp (__longjmp.S:68)
> 
>   Use of uninitialised value of size 4
>  at 0x80759DD: gray_convert_glyph_inner (ftgrays.c:1718)
>  by 0x8075CAB: gray_convert_glyph (ftgrays.c:1816)
>  by 0x8075628: ft_smooth_render_generic (ftsmooth.c:292)
>  by 0x8057ECA: FT_Render_Glyph_Internal (ftobjs.c:3932)
>  by 0x8057F41: FT_Render_Glyph (ftobjs.c:3972)
>  by 0x808E98F: (below main) (libc-start.c:226)
> 
>   Use of uninitialised value of size 4
>  at 0x80759EC: gray_convert_glyph_inner (ftgrays.c:1721)
>  by 0x8075CAB: gray_convert_glyph (ftgrays.c:1816)
>  by 0x8075628: ft_smooth_render_generic (ftsmooth.c:292)
>  by 0x8057ECA: FT_Render_Glyph_Internal (ftobjs.c:3932)
>  by 0x8057F41: FT_Render_Glyph (ftobjs.c:3972)
>  by 0x808E98F: (below main) (libc-start.c:226)
> 
> My knowledge of compiler details is too limited to really interpret
> it.  The variable `error' is already defined as `volatile', and AFAIK
> more is not needed to make longjmp work.

It's over my head as well. That Valgrind reports any warning related to this 
use of longjmp does seem significant; it suggests a problem that isn't limited 
to MinGW.

I wonder if you tried changing -fomit-frame-pointers to 
fno-omit-frame-pointers, and whether Valgrind still issues warnings in that 
case?

Maybe some Valgrind or GCC experts would be willing to investigate.

Tom

文林 Wenlin Institute, Inc.Software for Learning Chinese
E-mail: [email protected] Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯






___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-09 Thread Werner LEMBERG

> I've reproduced the crash with a different font: mssong.ttf, glyph
> number 1006. This font is available for free from Microsoft.

OK, this one I have.

> Here is the program that crashes with mssong.ttf, glyph number 1006:

Thanks, testing right now on my GNU/Linux box.

> Here's the makefile: [...]
>
> [...]
>
> CFLAGS = $(OPT_FLAGS) -mwindows -DUNICODE=1 -Wall $(INCLUDE) \
>  -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY \
>  -DFT_AVOID_LONGJMP=0

This won't compile.  You need -DFT2_BUILD_LIBRARY also.

> I built it and ran it as follows:
>
> freetype_debug_gray mssong.ttf 1006 > test_mssong.txt 2>&1

Adding FT2_DEBUG=any:5 to the environment, I get the same output as
you but complete, without crash.

> The output is shown below. The stuff at the end about "# of
> contours: -1" and "Glyph 22971" is mysterious.

Not at all: -1 for the number of contours specifies that it is a
composite glyph.  What follows are the subglyphs.

> Glyph 1006
>   # of contours: -1
>   xMin:   11  xMax:  241
>   yMin:  -21  yMax:  194
>   advance width (font units): 256
>   left side bearing (font units): 4
>   advance height (font units): 256
>   top side bearing (font units): 0
> Glyph 22971
>   # of contours: 1
>   xMin:4  xMax:  234
>   yMin:0  yMax:  215
>   Instructions size: 0
>   x advance: 10368
>   y advance: 0
>   linear x advance: 10616832
>   linear y advance: 10616832
> FT_Outline_Decompose: Out

Using valgrind, I get two warnings specific to the demo program:

   Use of uninitialised value of size 4
  at 0x808F02F: __longjmp (__longjmp.S:68)

   Use of uninitialised value of size 4
  at 0x80759DD: gray_convert_glyph_inner (ftgrays.c:1718)
  by 0x8075CAB: gray_convert_glyph (ftgrays.c:1816)
  by 0x8075628: ft_smooth_render_generic (ftsmooth.c:292)
  by 0x8057ECA: FT_Render_Glyph_Internal (ftobjs.c:3932)
  by 0x8057F41: FT_Render_Glyph (ftobjs.c:3972)
  by 0x808E98F: (below main) (libc-start.c:226)

   Use of uninitialised value of size 4
  at 0x80759EC: gray_convert_glyph_inner (ftgrays.c:1721)
  by 0x8075CAB: gray_convert_glyph (ftgrays.c:1816)
  by 0x8075628: ft_smooth_render_generic (ftsmooth.c:292)
  by 0x8057ECA: FT_Render_Glyph_Internal (ftobjs.c:3932)
  by 0x8057F41: FT_Render_Glyph (ftobjs.c:3972)
  by 0x808E98F: (below main) (libc-start.c:226)

My knowledge of compiler details is too limited to really interpret
it.  The variable `error' is already defined as `volatile', and AFAIK
more is not needed to make longjmp work.


Werner

___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-08 Thread Tom Bishop, Wenlin Institute

On Jan 1, 2011, at 11:31 PM, Werner LEMBERG wrote:

...
> Which font is it?  Maybe I already have it.  Otherwise, please send me
> the font privately for further investigation.

I've reproduced the crash with a different font: mssong.ttf, glyph number 1006. 
This font is available for free from Microsoft.

>> The difference between -fomit-frame-pointer and
>> -fno-omit-frame-pointer seems to be important, but maybe not.  With
>> GCC 4.5, it is currently making the difference between crashing or
>> not.
> 
> Can you try a different compiler like MSVC?

I don't have MSVC; maybe I'll try it eventually. In the meantime I won't use 
-fomit-frame-pointer with GCC.

A web search for "-fomit-frame-pointer MinGW longjmp" turns up a number of 
reports that the combination is error-prone.

There is still a chance the bug is in FreeType. I wrote a short test program 
that combines MinGW, -fomit-frame-pointer, setjmp and longjmp, without FreeType 
(or anything font-related), and it didn't crash.

Here is the program that crashes with mssong.ttf, glyph number 1006:

#include 
#include 
#include 
#include FT_FREETYPE_H

static char *DebugFreeType(char *fontname, int glyphnumber)
{
FT_Library ttEngine;
if (FT_Init_FreeType(&ttEngine) != 0) {
return "FT_Init_FreeType error";
}
FT_Face face;
if (FT_New_Face(ttEngine, fontname, 0, &face) != 0) {
return "FT_New_Face error";
}
FT_Set_Pixel_Sizes(face, 0, 162);
FT_Load_Glyph(face, glyphnumber, FT_LOAD_RENDER | FT_LOAD_NO_BITMAP);
return "OK";
} // DebugFreeType

int main(int argc, char **argv)
{
if (argc < 3) {
printf("Usage: freetype_debug_gray fontname glyphnumber\n");
return 0;
}
char *fontname = argv[1];
int glyphnumber = atoi(argv[2]);
char *s = DebugFreeType(fontname, glyphnumber);
printf("%s\n", s);
if (strcmp(s, "OK") != 0) {
return -1;
}
return 0;
} // main

---

Here's the makefile:

CC = mingw32-gcc
CXX = mingw32-g++

vpath %.c ../c \
../freetype/src/autohint ../freetype/src/bdf ../freetype/src/cff 
../freetype/src/cache ../freetype/src/gzip \
../freetype/src/base ../freetype/src/pcf ../freetype/src/pfr 
../freetype/src/psaux ../freetype/src/pshinter \
../freetype/src/psnames ../freetype/src/raster ../freetype/src/sfnt 
../freetype/src/smooth ../freetype/src/truetype \
../freetype/src/type1 ../freetype/src/cid ../freetype/src/type42 
../freetype/src/winfonts ../freetype/src/lzw \
../freetype/src/autofit

INCLUDE =-I../freetype/include -I../freetype/include/freetype

OPT_FLAGS = -Os -ggdb -fomit-frame-pointer
# OPT_FLAGS = -Os -ggdb -fno-omit-frame-pointer

CFLAGS = $(OPT_FLAGS) -mwindows -DUNICODE=1 -Wall $(INCLUDE) 
-DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY -DFT_AVOID_LONGJMP=0

# to set environment variable FT2_DEBUG:
# set FT2_DEBUG=any:5

OBJS = \
freetype_debug_gray.o \
bdf.o cff.o ftbase.o ftcache.o ftglyph.o ftgzip.o ftinit.o \
ftsystem.o pcf.o pfr.o psaux.o pshinter.o psnames.o raster.o \
sfnt.o smooth.o truetype.o type1.o type1cid.o type42.o winfnt.o 
fttype1.o \
ftbitmap.o ftlzw.o autofit.o \
ftdebug.o

freetype_debug_gray.exe: $(OBJS) $(RESOURCES)
$(CC) -static $(CFLAGS) $(OBJS) $(RESOURCES) -o $@

# Automatically generate dependencies, save them in .d files
%.d: %.c
$(CC) -MM $(CFLAGS) $< > $@
depends = $(OBJS:.o=.d)
include $(depends)

clean:
del *.o *.d *.exe



I built it and ran it as follows:

freetype_debug_gray mssong.ttf 1006 > test_mssong.txt 2>&1

The output is shown below. The stuff at the end about "# of contours: -1" and 
"Glyph 22971" is mysterious.

Best wishes,

Tom

Init_Context: new object at 0x003D77B8
FT_Stream_Open: opened `mssong.ttf' (2569116 bytes) successfully
sfnt_open_font: synthesize TTC
sfnt_init_face: 003D9350, 0
tt_face_load_font_dir: 003D9350
-- Number of tables: 16
-- Format version:   0x0001

  tagoffsetlength   checksum
  --
  EBDT  001e0368  0008807b  b079e788
  EBLC  002683e4  afb8  3044215a
  OS/2  010c  0056  59eb64de
  cmap  0164  05aa  37177270
  cvt   0710  02be  072903f0
  fpgm  09d0  000d  4aa192e8
  gasp  09e0  0010  001f0009
  glyf  09f0  001b8b72  32695904
  head  001b9564  0036  12c21a71
  hhea  001b959c  0024  02010141
  hmtx  001b95c0  ce46  b4da7bd8
  loca  001c6408  00019b04  e88fad52
  maxp  001dff0c  0020  689c0487
  name  001dff2c  0365  18395d95
  post  001e0294  0020  ffed000d
  prep  001e02b4  00b2  05dc4fcc
table directory loaded

sfnt_load_face: 003D9350

tt_face_lookup_table: 003D9350, `glyf' -- found table.
`head' -->
tt_face_lookup_table: 003D9350, `head' -- found table.
Units per EM:  256
IndexToLo

Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2011-01-01 Thread Werner LEMBERG
> A very short program (freetype_debug_gray.c) demonstrates the crash:
> [...]
>
> Unless there is a bug in that code,

At a first glance, the code looks fine.

> it seems the bug must be in MinGW
> GCC (4.5 and 3.4.4), or MS-Windows 7/Vista/XP, or FreeType
> 2.4.4.

I can try to replicate it on my GNU/Linux box, testing with valgrind
also.

> Possibly there is something the matter with MYFONT.TTF; still,
> ideally FreeType shouldn't crash no matter what is in the font.

Yep.

> If anyone is willing and able to investigate this, I'll try to come
> up with a smaller font containing just one glyph that causes the
> same crash. (Glyph 7211 is actually fairly simple, with only one
> contour; it's not the more intricate one with which the problem
> first occurred.)

Which font is it?  Maybe I already have it.  Otherwise, please send me
the font privately for further investigation.

> glyph count mismatch!  loca: 11664, maxp: 11663

This should be harmless.

> The output suddenly stops with "con", when the program
> crashes. Probably some output is lost (unflushed buffer?); I doubt
> the crash occurs in the middle of printing "conic".

The flushing out of stderr messages is not forced by FreeType but is
done by the OS.  Since FreeType doesn't emit any other messages this
isn't a problem normally.

> The difference between -fomit-frame-pointer and
> -fno-omit-frame-pointer seems to be important, but maybe not.  With
> GCC 4.5, it is currently making the difference between crashing or
> not.

Can you try a different compiler like MSVC?


Werner

___
Freetype-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] avoiding a longjmp crash in ftgrays.c

2010-12-27 Thread Tom Bishop, Wenlin Institute
Dear FreeTypers,

A very short program (freetype_debug_gray.c) demonstrates the crash:

#include 
#include 
#include 
#include FT_FREETYPE_H

static char *DebugFreeType(void)
{
FT_Library ttEngine;
if (FT_Init_FreeType(&ttEngine) != 0) {
return "FT_Init_FreeType error";
}
char ttName[] = "MYFONT.TTF";
FT_Face face;
if (FT_New_Face(ttEngine, ttName, 0, &face) != 0) {
return "FT_New_Face error";
}
FT_Set_Charmap(face, face->charmaps[1]);
FT_Set_Pixel_Sizes(face, 0, 162);
FT_Load_Glyph(face, 7211, FT_LOAD_RENDER | FT_LOAD_NO_BITMAP);
return "OK";
} // DebugFreeType

int main(void)
{
char *s = DebugFreeType();
printf("%s\n", s);
if (strcmp(s, "OK") != 0) {
return -1;
}
return 0;
} // main

==
Unless there is a bug in that code, it seems the bug must be in MinGW GCC (4.5 
and 3.4.4), or MS-Windows 7/Vista/XP, or FreeType 2.4.4. Possibly there is 
something the matter with MYFONT.TTF; still, ideally FreeType shouldn't crash 
no matter what is in the font. If anyone is willing and able to investigate 
this, I'll try to come up with a smaller font containing just one glyph that 
causes the same crash. (Glyph 7211 is actually fairly simple, with only one 
contour; it's not the more intricate one with which the problem first occurred.)

This is the makefile:

CC = mingw32-gcc
CXX = mingw32-g++
#CC=i386-mingw32-gcc
#CXX = i386-mingw32-g++

vpath %.c ../c \
../freetype/src/autohint ../freetype/src/bdf ../freetype/src/cff 
../freetype/src/cache ../freetype/src/gzip \
../freetype/src/base ../freetype/src/pcf ../freetype/src/pfr 
../freetype/src/psaux ../freetype/src/pshinter \
../freetype/src/psnames ../freetype/src/raster ../freetype/src/sfnt 
../freetype/src/smooth ../freetype/src/truetype \
../freetype/src/type1 ../freetype/src/cid ../freetype/src/type42 
../freetype/src/winfonts ../freetype/src/lzw \
../freetype/src/autofit

INCLUDE =-I../freetype/include -I../freetype/include/freetype

OPT_FLAGS = -Os -ggdb -fomit-frame-pointer
# OPT_FLAGS = -Os -ggdb -fno-omit-frame-pointer

CFLAGS = $(OPT_FLAGS) -mwindows -DUNICODE=1 -Wall $(INCLUDE) 
-DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY -DFT_AVOID_LONGJMP=0

OBJS = \
freetype_debug_gray.o \
bdf.o cff.o ftbase.o ftcache.o ftglyph.o ftgzip.o ftinit.o \
ftsystem.o pcf.o pfr.o psaux.o pshinter.o psnames.o raster.o \
sfnt.o smooth.o truetype.o type1.o type1cid.o type42.o winfnt.o 
fttype1.o \
ftbitmap.o ftlzw.o autofit.o \
ftdebug.o

freetype_debug_gray.exe: $(OBJS)
$(CC) -static $(CFLAGS) $(OBJS) -o $@

# Automatically generate dependencies, save them in .d files
%.d: %.c
$(CC) -MM $(CFLAGS) $< > $@
depends = $(OBJS:.o=.d)
include $(depends)

clean:
del *.o *.d *.exe

=
I set the debug level and run the program like this at the Windows XP command 
line (to capture stdout and stderr):

set FT2_DEBUG=any:5

freetype_debug_gray > test_crash.txt 2>&1

The resulting file test_crash.txt is this:

Init_Context: new object at 0x003D77B8
FT_Stream_Open: opened `MYFONT.TTF' (10904212 bytes) successfully
sfnt_open_font: synthesize TTC
sfnt_init_face: 003D9310, 0
tt_face_load_font_dir: 003D9310
-- Number of tables: 14
-- Format version:   0x0001

 tagoffsetlength   checksum
 --
 OS/2  00ec  004e  caf25b27
 cmap  013c  0720  d133e179
 cvt   085c  0010  02e801e8
 fpgm  086c  0153  c960b19b
 glyf  09c0  00a4e902  492c51de
 head  00a4f2c4  0036  d925c905
 hhea  00a4f2fc  0024  072e2ff1
 hmtx  00a4f320  b63c  4f077d01
 loca  00a5a95c  b640  5ec518e4
 maxp  00a65f9c  0020  2fb507c1
 mort  00a65fbc    
 name  00a65fbc  02a2  de87d200
 post  00a66260  0020  00030066
 prep  00a66280  0013  bf3658bc
table directory loaded

sfnt_load_face: 003D9310

tt_face_lookup_table: 003D9310, `glyf' -- found table.
`head' -->
tt_face_lookup_table: 003D9310, `head' -- found table.
Units per EM: 1000
IndexToLoc:  1
loaded

`maxp' -->
tt_face_lookup_table: 003D9310, `maxp' -- found table.
numGlyphs: 11663
loaded

`cmap' -->
tt_face_lookup_table: 003D9310, `cmap' -- found table.
loaded

`name' -->
tt_face_lookup_table: 003D9310, `name' -- found table.
loaded

`post' -->
tt_face_lookup_table: 003D9310, `post' -- found table.
FormatType:   0x3
isFixedPitch:  no
loaded

`hhea' -->
tt_face_lookup_table: 003D9310, `hhea' -- found table.
Ascender:930
Descender:  -225
number_Of_Metrics: 11663
loaded

`hmtx' -->
tt_face_lookup_table: 003D9310, `hmtx' -- found table.
loaded

`vertical hhea' -->
tt_face_lookup_table: 003D9310, `vhea' -- could not find table
missing

`os2' -->
tt_face_lookup_table: 003D9310, `OS/2' -- found table.
sT