[OpenJDK 2D-Dev] JNI crashes in FontManager code

Igor Nekrestyanov Igor.Nekrestyanov at Sun.COM
Sun Oct 19 10:40:51 UTC 2008

>> Suggested changes seems reasonable.
>> However, i failed to invent testcase to reproduce this issue.
>> Could you please describe what google test is doing in regard to the 
>> font code?
>> It first glance it seems that the only way to get into freetypeScaler.c 
>> is through synchronized methods and
>> env variable gets overridden every time. So, it seems that it should 
>> match current thread always.
>> I am interested to understand what i am missing here.
> I think what could happen here is that FreeType doesn't read the whole
> font file in one go during initialization, but instead reads the glyphs
> on demand when actually scaling. It's possible that this is triggered
> from a different thread than the one used during initialization. I don't
> know about Hotspot, but I know that some VMs simply don't care (so much
> as others) about what JNIEnv* they use when calling a JNI function.
Well, I would expect that any read requests are triggered by request to 
freetype glue layer to retrieve glyph image or
glyph metrics. And any call to glue layer should reset JNIEnv field 
(explicitly or by calling setupFTContext()).
Theoretically, this should guarantee that JNIEnv is matching current 
thread unless
there are other code changes that break one of these assumptions.


More information about the 2d-dev mailing list