JDK-6952694 : resolve_external_guard() should probably check for deleted_handle()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs18
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2010-05-14
  • Updated: 2014-06-30
  • Resolved: 2014-06-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Relates :  
JDK-6949515 - VM crash when calling GetMethodDeclaringClass
Description
This issue came up during code review of the following bug fix:

    6949515 3/3 VM crash when calling GetMethodDeclaringClass

On May 14, 2010, at 12:57 PM, Daniel D. Daugherty wrote:

> On 5/14/2010 8:55 AM, Karen Kinnear wrote:
>> Dan,
>>
>> Change looks good.
>
> Thanks!
>
>
>> One question - resolve_external_guard checks for badJNIHandle, should
>> it also check for deleted_handle()?
>
> That's a really good question. The "deleted_handle" stuff was added
> by this delta:
>
> D 1.8 98/04/15 10:24:56 steffen 10 8    00013/00013/00140
> MRs:
> COMMENTS:
>
>
> I added resolve_external_guard() via this delta:
>
> D 1.21.1.1 00/05/10 16:11:36 dcubed 29 23       00010/00000/00161
> MRs:
> COMMENTS:
> 4324823 - Add resolve_external_guard() support.
>
> (Yes, I'm adding a call to a routine I wrote 10 years ago; let the
> "old" jokes commence...)
>
>
> Fred changed resolve_non_null() to not allow deleted_handle() to
> be returned via this delta:
>
> D 1.26 01/06/14 16:21:55 foliver 34 33  00002/00000/00173
> MRs:
> COMMENTS:
> 4462061: Prevent a JNI handle from being dereferenced after that handle
> was explicitly deleted, at least in some cases.
>
>
> The "at least in some cases" and my reading of 4462061 make me think
> that I'd want to make that change separately and with a full round of
> testing to make sure things didn't unexpectedly regress...
>
> Would you be okay if I filed a new bug for that change and did it
> separately? For this bug fix, I'm still targeting:
>
>   OpenJDK6 (HSX-16), HSX-17, HSX-18 and now HSX-19
>   I may have to see if the fix needs to go into HSX16.foo
>   or HSX-17.foo also...
>
> For the new bug, I will just push it to HSX-19...
>
> Does this sound like a good plan?
>
> Dan
Comments
JNIHandles _deleted_handle is a local handle that's been deleted so should not come back into the JVM from jvmti or jni code. resolve_external_guard looks like this: inline oop JNIHandles::resolve_external_guard(jobject handle) { if (handle == NULL) return NULL; oop result = *(oop*)handle; assert(result != deleted_handle(), "does anyone return a deleted handle?"); if (result == NULL || result == badJNIHandle) return NULL; return result; }; This assertion hasn't fired, so there isn't an issue. We don't want to return NULL to hide deleted_handles coming into the JVM from the jvmti interfaces. See comment in resolve_non_null() // Don't let that private _deleted_handle object escape into the wild. assert(result != deleted_handle(), "Used a deleted global handle."); Closing as not an issue.
30-06-2014
EVALUATION The description pretty much says it all.
14-05-2010