[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