JDK-8301402 : os::print_location gets is_global_handle assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-01-30
  • Updated: 2023-02-06
  • Resolved: 2023-02-01
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 21
21 b08Fixed
Related Reports
Relates :  
Description
The os::print_location() code is trying to figure out what the data is and gets an assert

    error_msg=error_msg@entry=0x1532167670d0 "assert(!is_global_tagged(handle) || is_storage_handle(global_handles(), global_ptr(handle))) failed", detail_fmt=detail_fmt@entry=0x15321667c15f "invalid storage")

It should just return false for this case and not get a secondary assert.

#12 0x0000153215b6a713 in JNIHandles::is_global_handle (handle=handle@entry=0x1532166997aa)
    at src/hotspot/share/runtime/jniHandles.cpp:245
#13 0x00001532160b6388 in os::print_location (st=st@entry=0x153193ffc310, x=23304868566954, verbose=verbose@entry=false)
    at src/hotspot/share/runtime/os.cpp:1155
#14 0x00001532160cead2 in os::print_register_info (st=0x153193ffc310, context=0x153216c204e0 <g_stored_assertion_context>)
--Type <RET> for more, q to quit, c to continue without paging--
    at src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp:595
#15 0x000015321651ce4b in VMError::report (st=st@entry=0x153193ffc310, _verbose=_verbose@entry=true)
    at src/hotspot/share/utilities/vmError.cpp:867

Or ask a safer question.
Comments
Changeset: ef0d0a70 Author: Axel Boldt-Christmas <aboldtch@openjdk.org> Date: 2023-02-01 09:47:15 +0000 URL: https://git.openjdk.org/jdk/commit/ef0d0a7092df7b3ce098fb25860fb839fd34c944
01-02-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/12312 Date: 2023-01-31 09:27:50 +0000
31-01-2023

Problem is that JNIHandles::is_[weak_]global_handle assumes that the jobject handle is a valid handle. I restricted this because we now tagged up all different handle types. But I did not think of the print_location code which sends in none handles. Either revert the handle check to always checking storage and ignore the tags. Or add another is_*_handle method which takes an void*/address and makes no assumptions, just checks the underlying storage, which can be used by print_location. Looking at this JNIHandles::is_weak_global_handle seems more fragile as when it gets called from checked_jni_DeleteWeakGlobalRef we do not validate the storage at all. While for checked_jni_DeleteGlobalRef (which uses JNIHandles::is_global_handle) is validated with jniCheck::validate_object. So maybe just always checking the storage is the proper solution even if we have contexts where just checking the tag is valid.
31-01-2023