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

Roman Kennke roman.kennke at aicas.com
Sun Oct 19 15:54:17 UTC 2008


Hi Igor,

> >> 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.

I see. You are probably right. But: I found at least one call into
Freetype that does not setup the env correctly, that is in
getGlyphCodeNative(). I don't know if this is supposed to read from the
font file, but we probably cannot guarantee that it doesn't. 

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt




More information about the 2d-dev mailing list