JDK-8162766 : Unsafe_DefineClass0 accesses raw oops while in _thread_in_native
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 8u40
- Priority: P2
- Status: Closed
- Resolution: Fixed
- Submitted: 2016-07-29
- Updated: 2017-11-29
- Resolved: 2016-10-11
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.
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 7 | JDK 8 |
|---|---|
7Resolved  |
8u152 b01Fixed |
Related Reports
|
Relates :
|
Description
The problem is that get_class_loader resolves handles while in native.
If line 989 gets executed while GC is moving cls then we may get an incorrect value or even a crash if we are unlucky.
The same goes for line 992.
At line 993 and 994 we may read a stale value for k->class_loader() and return a JNI handle to an invalid object.
988 static jobject get_class_loader(JNIEnv* env, jclass cls) {
989 if (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) {
990 return NULL;
991 }
992 Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
993 oop loader = k->class_loader();
994 return JNIHandles::make_local(env, loader);
995 }
Suggested fix is to call get_class_loader before transitioning to native in Unsafe_DefineClass0
See email trail at:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/024022.html
Comments
|