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