Author Topic: [Solved] Access Violation in FT_Load_Char (Read 3858 times)

pdinklag · « **on:** January 18, 2012, 10:38:02 pm »

I'm facing a weird problem working on JSFML.
While experimenting with Fonts and Texts, I hit on sudden access violations in the C++ part that appeared very random. With the help of a disassembler, I could trace back the problem and it definitely occurs in some subsequent (2 further call levels, can't find it exactly) code invoked by FT_Load_Char. Indeed, I can reproduce the problem by making it load a new glyph every frame, after a while it would crash. However, this only happens from within a Java VM, I cannot reproduce it in a pure C++ program.

The glyph which it fails to load seems to be arbitrary. Trying to read any glyph from FreeSerif crashes instantly, but it works fine with FreeMono up to a certain point. This never seems to happen with the SFML default font, which is probably why I never noticed it so far.

I noticed that under Windows (building with MinGW), freetype is linked statically into SFML. Which version is it exactly? I would like to examine the freetype sources further to find exactly the line of code that causes the access violation. Are there any known problems or things to know about freetype that might be involved here?

I will also try to reproduce this problem on Linux tomorrow.

Laurent · « **Reply #1 on:** January 18, 2012, 10:56:52 pm »

You're the first one to report such a problem with FreeType, it's strange.

The version used in SFML 2 is 2.4.4.

pdinklag · « **Reply #2 on:** January 19, 2012, 08:50:27 am »

Well, it is not necessarily a problem with FreeType. A rough guess is that there's some kind of incompatibility between the JVM heap allocator and whatever freetype uses (if it's anything special). I'm not sure, but I'll try to find out.

pdinklag · « **Reply #3 on:** January 19, 2012, 02:52:01 pm »

Meh, the FreeType source code is quite a mess...
Anyway, the problem occurs on Linux in the exact same way, and the stack trace is a lot more detailed:
http://pastebin.com/f6wwgenX

Unfortunately, this doesn't really help me find out what's wrong exactly, but I guess it's safe to say that it's not the JVM itself causing trouble, because the OpenJDK implementation on Linux should be quite different from the Sun/Oracle implementation I use on Windows.

I'm going to push my testing code to github later.

pdinklag · « **Reply #4 on:** January 19, 2012, 07:53:32 pm »

Alright, debugged this with help of a disassembler. freetype fails to lookup a glyph from one of its internal maps.

More accurately, ps_unicodes_char_index tries to read from a data pointer from one of freetype's many CMap records (likely TT_CMapRec_, but I cannot tell for sure). The pointer looks valid (location fits well into the heap space) but is not, so whatever it pointed to most likely already got freed again.

So apparently, this is an issue with heap allocators. I'm not sure what I can do about this, if anything. Going to try and find out now. Maybe this is something for the freetype developers rather than this place.

pdinklag · « **Reply #5 on:** January 19, 2012, 08:38:04 pm »

Problem solved. Actually, this was my fault, but unknowingly.
I did not know that freetype still requires the input stream after the font was loaded. I released the memory and thus, freetype failed to read from it.

This is definitely a hazard for anybody using sf::Font::LoadFromMemory, because the memory must not be released before the font is no longer used.

EDIT: I also just realized that the documentation already says so. My bad. :roll:

Laurent · « **Reply #6 on:** January 19, 2012, 09:51:52 pm »

Quote

I also just realized that the documentation already says so. My bad.

:twisted: