Bug ID: JDK-8267842 SIGSEGV in get_current_contended

Versions (Unresolved/Resolved/Fixed)

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 16	JDK 17
16.0.2Fixed	17 b25Fixed

In ThreadService::get_current_contended_monitor, "wait_obj" or "enter_obj" can be observed to be NULL after NULL check due to concurrent modification. These two variables and the memory locations from which they were read from are not declared volatile, so C++ compilers are allowed to generate code which reloads them from memory after the NULL checks.

Crashes with SIGSEGV were observed on s390 when running the test serviceability/monitoring/ThreadInfo/GetLockOwnerName/GetLockOwnerName.java since May 15. The problem is reproducible with fastdebug build, but not with slowdebug.

#  SIGSEGV (0xb) at pc=0x000003ff98f1ce46, pid=48257, tid=48285
#
# JRE version: OpenJDK Runtime Environment (17.0.0.1) (fastdebug build 17.0.0.1-internal+0-adhoc.openjdk.jdk-dev)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 17.0.0.1-internal+0-adhoc.openjdk.jdk-dev, mixed mode, sharing, tiered, compressed oops, co
mpressed class ptrs, g1 gc, linux-s390x)
# Problematic frame:
# V  [libjvm.so+0xf1ce46]  ObjectMonitor::object() const+0x156

Stack from gdb with line numbers:
#7  <signal handler called>
#8  ObjectMonitor::object (this=0x0) at /openjdk/nb/linuxs390x/jdk-dev/src/hotspot/share/oops/weakHandle.hpp:56
#9  0x000003ff9921fd68 in ThreadService::get_current_contended_monitor (thread=thread@entry=0x3ff300aa720)
    at /openjdk/nb/linuxs390x/jdk-dev/src/hotspot/share/services/threadService.cpp:242
#10 0x000003ff992224f6 in ThreadSnapshot::initialize (this=this@entry=0x3ff300ae380, t_list=<optimized out>, 
    thread=thread@entry=0x3ff300aa720)
    at /openjdk/nb/linuxs390x/jdk-dev/src/hotspot/share/services/threadService.cpp:885
#11 0x000003ff99222e60 in ThreadDumpResult::add_thread_snapshot (this=this@entry=0x3ff69d7d5b0, thread=0x3ff300aa720)
    at /openjdk/nb/linuxs390x/jdk-dev/src/hotspot/share/runtime/threadSMR.hpp:279
#12 0x000003ff98dfc360 in jmm_GetThreadInfo (env=<optimized out>, ids=<optimized out>, maxDepth=<optimized out>, 
    infoArray=<optimized out>) at /openjdk/nb/linuxs390x/jdk-dev/src/hotspot/share/services/management.cpp:1106

Fix Request (16u) Bug was discovered by new test GetLockOwnerName in 17, but the get_current_contended_monitor function is also sensitive to the same race condition in 16u. Making the two member fields volatile is a very low risk. Performance regression is not expected and was not observed so far. Without the fix, the VM may crash very sporadically if the C++ compiler exploits certain optimizations depending on platform and compiler. Fix doesn't apply cleanly, but is trivial to resolve: https://github.com/openjdk/jdk16u/pull/125
02-06-2021
Changeset: 1e29005a Author: Martin Doerr <mdoerr@openjdk.org> Date: 2021-05-31 08:27:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/1e29005a22c7951242cf3b0d8cf2e6adc0b7b315
31-05-2021
> These two variables and the memory locations from which they were read from are not declared volatile, so C++ compilers are allowed to generate code which reloads them from memory after the NULL checks. While strictly speaking under the memory model all reads from non-volatile locations can be treated as idempotent by the compiler, it seems an extremely nonsensical thing for a compiler to do in the current context.
28-05-2021
Moving from hotspot/runtime -> hotspot/svc since the ThreadService is owned by the Serviceability team.
27-05-2021

Relates :	JDK-8263901 - RunThese30M.java failed with SIGSEGV in Threads::owning_thread_from_monitor_owner
Relates :	JDK-8265153 - add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
Relates :	JDK-8153224 - Monitor deflation prolong safepoints