[OpenJDK 2D-Dev] What is the point of CloseTTFontFileFunc?

[Phil Race]

I can only suppose the author thought he was going to pass the platName 
(which
would be the font file path) to some code that would use it to somehow close
an open descriptor on that file. But clearly it does nothing of the sort and
an up-call to the java font object (like in the read function) would not 
need
that information anyway. So it looks redundant. I don't see how it would
relate to the crash. That *may* be caused by some simultaneous use 
and/or freeing
in different threads of files created using Font.createFont(..) and are 
now bing released.
I've also seen crashes where admins clean out the /tmp folder whilst the 
JRE is running using
font files there. But that would probably not involve the disposer code.

-phil.

On 12/29/2014 3:03 AM, Andrew Dinn wrote:
> Hi again,
>
> Trying a second time . . . anyone have an answer to this question?
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
> (USA), Michael O'Neill (Ireland)
>
> On 19/12/14 11:08, Andrew Dinn wrote:
>> Hi All,
>>
>> I am looking at a problem Red Hat customers have reported with True Type
>> fonts where they are seeing a Hotspot crash using JDK7. the problem
>> relates to the use of TT font scalers and, in particular to code called
>> under native methods initNativeScaler and disposeNativeScaler of class
>> sun.font.FreetypeFontScaler.
>>
>> While investigating this I looked at the stream close function
>> CloseTTFontFileFunc provided for the scaler in freetypeScaler.c and was
>> rather confused as to what it was supposed to achieve. n.b. the code
>> below from the release version of Icedtea7 which caused the problem
>> appears still to exist unchanged in the latest jdk7u, jdk8u and jdk9).
>>
>> /* NB: is it ever called? */
>> static void CloseTTFontFileFunc(FT_Stream stream) {
>>      FTScalerInfo *scalerInfo = (FTScalerInfo *) stream->pathname.pointer;
>>      JNIEnv* env = scalerInfo->env;
>>      jclass tmpClass = (*env)->FindClass(env, "sun/font/TrueTypeFont");
>>      jfieldID platNameField =
>>           (*env)->GetFieldID(env, tmpClass, "platName",
>> "Ljava/lang/String;");
>>      jstring platName = (*env)->GetObjectField(env,
>>                                                scalerInfo->font2D,
>>                                                platNameField);
>>      const char *name = JNU_GetStringPlatformChars(env, platName, NULL);
>>      JNU_ReleaseStringPlatformChars(env, platName, name);
>> }
>>
>> Is there any point in calling JNU_GetStringPlatformChars and then
>> JNU_ReleaseStringPlatformChars? This appears simply to malloc a copy of
>> the platname string, albeit perhaps with some multibyte chars replaced
>> with '?', and then to immediately free the allocated string. Is there
>> any good reason for this?
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>
>>
>>