[OpenJDK 2D-Dev] RFR 8078654: CloseTTFontFileFunc callback should be removed

[Phil Race]

I don't read it the way you do.
The code is getting a reference to the java "Font2D" - almost
certainly an instance of the "TrueTypeFont" subclass
That is NULL which is the source of the crash.
But if it does retrieve it then it wants the value of the String 
'platName' field.
For TrueTypeFont that always
  holds the name of the file that contains the font.
It then asks for the name of the file in platform encoding ..

    const char *name = JNU_GetStringPlatformChars(env, platName, NULL);

  but  promptly releases it again without doing anything ...

  JNU_ReleaseStringPlatformChars(env, platName, name);

These two calls are a matching pair, the latter isn't freeing
some 'platform allocated' resource simply referenced by the VM.
The first JNU call allocated that resource.

It is as if there was an intention to do something file system
related with that name between the Get and the Release
but you can't close a file descriptor based on the file name,
so it looks like an imcomplete piece of work to me.

-phil.

On 04/30/2015 01:33 AM, Andrew Dinn wrote:
> On 29/04/15 23:23, Phil Race wrote:
>> I think this fix should be fine. There should be no reason
>> we need to do anything here as the file should already be
>> closed by the Java side which has demonstrably gone away
>> so should have already closed the file before then.
> That's true and I'm glad to hear this fix will go into jdk9 (and
> hopefully 7 and 8). Please let me know if the webrev is ok or you need
> any further input.
>
> However, I'll note in passing that the closefn was never there in order
> to ensure the JVM closes the file (at least it has been as is for as far
> back as I can check the source). The callback looks for some String
> memory to free, specifically a char buffer associated with a particular
> type of Windows character set -- it trips up because the reference to
> the object holding the String returns null. When you investigate the
> provenance of the String it turns out that it is always just a normal
> String with a normal char buffer -- and therefore the attempt to free
> this char buffer is at best misguided. That's the real reason why this
> callback is redundant.
>
> regards,
>
>
> Andrew Dinn
> -----------
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150430/b43fabc5/attachment.html>