Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
17
-
b23
-
generic
-
generic
Description
The Thread-SMR project added a couple of counter based tests for
ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName():
nsk/monitoring/ThreadInfo/isSuspended/issuspended002.java
nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java
See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".
The tests have been moved/renamed to:
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002/TestDescription.java
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java
I've created a time based test for ThreadMXBean.getThreadInfo()
and ThreadInfo.getLockOwnerName(). This time based test is more
appropriate for use in stress kits instead of a counter based test like
issuspended002 or find006.
I created the test for investigating the following bug:
JDK-8263901 RunThese30M.java failed with SIGSEGV in Threads::owning_thread_from_monitor_owner
and I've verified that this test does exercise the crashing thread's
code path fromJDK-8263901. However, the getThreadInfo() and
getLockOwnerName() APIs do not use nested ThreadsListHandles
and I believe that's the root cause forJDK-8263901. I wasn't able
to prove my theory so I closedJDK-8263901 as not reproducible,
but the test I developed is still quite useful for exercising the use
of ThreadsListHandles by getThreadInfo() when gathering a thread's
info either at a safepoint or at a non-safepoint.
ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName():
nsk/monitoring/ThreadInfo/isSuspended/issuspended002.java
nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java
See "
The tests have been moved/renamed to:
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002/TestDescription.java
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java
I've created a time based test for ThreadMXBean.getThreadInfo()
and ThreadInfo.getLockOwnerName(). This time based test is more
appropriate for use in stress kits instead of a counter based test like
issuspended002 or find006.
I created the test for investigating the following bug:
and I've verified that this test does exercise the crashing thread's
code path from
getLockOwnerName() APIs do not use nested ThreadsListHandles
and I believe that's the root cause for
to prove my theory so I closed
but the test I developed is still quite useful for exercising the use
of ThreadsListHandles by getThreadInfo() when gathering a thread's
info either at a safepoint or at a non-safepoint.
Attachments
Issue Links
- relates to
-
JDK-8266130 convert Thread-SMR stress tests from counter based to time based
-
- Resolved
-
-
JDK-8167108 inconsistent handling of SR_lock can lead to crashes
-
- Resolved
-
-
JDK-8263901 RunThese30M.java failed with SIGSEGV in Threads::owning_thread_from_monitor_owner
-
- Resolved
-
-
JDK-8267842 SIGSEGV in get_current_contended_monitor
-
- Resolved
-
(1 links to)