-
Bug
-
Resolution: Fixed
-
P2
-
hs24, hs25
-
master
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8008043 | 8 | Yumin Qi | P2 | Closed | Fixed | b77 |
JDK-8019714 | 7u60 | Yumin Qi | P2 | Resolved | Fixed | b01 |
JDK-8019447 | 7u45 | Yumin Qi | P2 | Closed | Fixed | b01 |
JDK-8017596 | 7u40 | Yumin Qi | P2 | Resolved | Fixed | b31 |
JDK-8007435 | hs25 | Yumin Qi | P2 | Closed | Fixed | b18 |
It appears that moving the _thread_id variable broke an undocumented assumption in WindbgX86Thread.java in the SA:
// another hack here is that we use sys thread id instead of handle.
// windbg can't get details based on handles it seems.
// I assume that osThread_win32 thread struct has _thread_id (which
// sys thread id) just after handle field.
this.sysId = (int) addr.addOffsetTo(debugger.getAddressSize()).getCIntegerAt(0, 4, true);
Now that the system thread id is no longer located right after the thread HANDLE this obviously won't work.
This breaks for example "jstack -F <pid>" which is the common way to inspect a hung VM on Windows.
ILW=HLH => P2
I=H SA on windows is basically useless for real usage
L=L not super-common to use, but "jstack -F" is an exported interface
W=H no known work-around
- backported by
-
JDK-8017596 SA on windows thread inspection is broken
- Resolved
-
JDK-8019714 SA on windows thread inspection is broken
- Resolved
-
JDK-8007435 SA on windows thread inspection is broken
- Closed
-
JDK-8008043 SA on windows thread inspection is broken
- Closed
-
JDK-8019447 SA on windows thread inspection is broken
- Closed
- duplicates
-
JDK-8016828 SA on windows thread inspection is broken
- Closed
- relates to
-
JDK-7171422 Change 7161732 breaks SA on Windows
- Resolved
-
JDK-7161732 Improve handling of thread_id in OSThread
- Closed