JDK-8265153 : add time based test for ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName()
- Type: Enhancement
- Component: core-svc
- Sub-Component: java.lang.management
- Affected Version: 17
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2021-04-13
- Updated: 2021-05-27
- Resolved: 2021-05-15
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 17 |
|---|
17 b23Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
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 from JDK-8263901. However, the getThreadInfo() and
getLockOwnerName() APIs do not use nested ThreadsListHandles
and I believe that's the root cause for JDK-8263901. I wasn't able
to prove my theory so I closed JDK-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.
Comments
|