RFR: 8025922 JNI access to Strings need to check if the value field is non-null

Staffan Larsen staffan.larsen at oracle.com
Fri Oct 4 05:31:42 PDT 2013


On 4 okt 2013, at 14:24, David Holmes <David.Holmes at oracle.com> wrote:

> On 4/10/2013 10:02 PM, Staffan Larsen wrote:
>> 
>> On 4 okt 2013, at 13:54, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>>> Hi Staffan,
>>> 
>>> On 4/10/2013 9:23 PM, Staffan Larsen wrote:
>>>> If the String constructor has not completed, then we can't access the String value. It is still possible to do this from JNI, but it should not crash the VM.
>>>> 
>>>> This was found while fixing a debugger issue (JDK-8021897) where stepping into the String constructor crashes the JVM. The fix for JDK-8021897 requires changes on the JDK side. Those changes will also include a JDI test for that issue, but won't be pushed until this change reaches jdk8-tl.
>>> 
>>> Other than the debugger case is there any other case where these JNI calls can occur before the constructor has completed? At the moment I'm not sure if this is really a JNI problem or a debugger problem - surely there are many objects that the debugger may access partially initialized which might then lead to errors/crashes?
>> 
>> From JNI you can do AllocObject() and then GetStringLength() and it will cause the same crash. I'd love to include a test for this, but alas, our test harness does not support native code.
> 
> Hmmmm. So that exposes a hole in the JNI specification. You can create unconstructed objects and then invoke JNI functions on them and there is no clear spec as to what should happen. What you have coded seems quite reasonable but for the get*Chars method contradicts the specification which states that it "Returns NULL if and only if an invocation of this function has thrown an exception." And the only exception listed is OOME.

Yeah, I had some problem with that statement as well, but figured this was the best I could do.

> 
> Impossible to meet that spec given the existence of AllocObject.
> 
> Reviewed. ;-)

Thanks,
/Staffan

> 
> Thanks,
> David
> 
> 
> 
>> /Staffan
>> 



More information about the hotspot-runtime-dev mailing list