Re: [Devel] Bug in FT New Memory Face?

[David Turner]

Hello Michael,

> 
> Hello
> 
> My application extracts a font file from a pdf file
> and writes it into a file to be read with FT_New_Face()
> and everything works as expected.
> 
> Now I wanted to optimize this application and read
> the font file as it is already in memory with
> FT_New_Memory_Face(), but know the application crashes
> or FT_Load_Glyph() returns with error code 2945.
> 
> Stack trace when the application crashes:
> fd1019f8   ec08e88d  _realloc + 0000002d
> fd101a20   ec083733  realloc + 0000004f
> fd101a44   ecdfc8dd  ft_realloc + 0000001d
> fd101a58   ecdfe2f2  FT_GlyphLoader_Check_Points + 00000196
> fd101a94   ece192b3  TT_Load_Simple_Glyph + 0000008f
> fd101aec   ece19b31  load_truetype_glyph + 00000271
> fd101b88   ece1a743  TT_Load_Glyph + 00000337
> fd101c58   ece2057b  Load_Glyph + 0000007b
> fd101c80   ecdfeb2a  FT_Load_Glyph + 000001ae
> fd101cc0   80053bde  FT2Font::getGlyphPixmap(unsigned short) + 000001d6
> fd101d0c   80053fc4  FT2Font::drawChar(BView *, int, int, int, int, int,
> unsigned short) + 00000038
> ...
> 
> Is this a known bug?
>
No, but the bug your describing seems very strange. If you're on Unix,
the stream implementation automatically uses memory-mapped files, so
using FT_New_Memory_Face shouldn't change anything to the program's
behaviour.

Could you run the program with ElectricFence to detect some problems ?
Or could you send me and Werner, one of these faulty fonts to let us
inspect it. The smaller the font, the better..

Regards,

- David