JDK-8000973 : SA on windows thread inspection is broken
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs24,hs25
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-10-16
  • Updated: 2013-07-04
  • Resolved: 2013-06-21
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
After the change JDK-7161732 (which came in 8-b42) the SA on windows cannot inspect the VM threads.
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.

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

The failures in my previous comment happened in Promotion testing of JDK7u40 b30 (Run 2013-06-22) probably built before the fix was checked in.

Above there's mention of 6326210 causing some exclusion. I'd be keen to know if that bug still reproduced with current builds, and if that exclusion was still relevant...

This bug has a fix integated in various places - when we say "more failures", are they in places that should have the fix, or that do not? i.e. are you saying the fix didn't work, or is there a further backport required?

Some more failures managed to happen. RULE nsk/sajdi/ThreadReference/frames_ii/frames_ii002 Exception sun.jvm.hotspot.debugger.DebuggerException: Windbg Error: GetThreadIdBySystemId failed! RULE nsk/sajdi/VMCannotBeModifiedException/thrown/thrown003 Exception sun.jvm.hotspot.debugger.DebuggerException: Windbg Error: GetThreadIdBySystemId failed!

As far as I understand 6326210 it already has fix (well, link to webrev does not work so it's just my impression). I believe that would be reasonable to integrate both 6326210 and 8000973 at the same time

what's with test base? Will it be fixed to catch that next time?

SQE-OK Ingemar ��berg, SQE

This is the failure matching history for JDK-6326210: http://vmsqe-app.russia.sun.com/surl/Ye It hasn't matched any failures since 2013-05-07 (Later matches also has JDK-7190247 as matching bug.)

I will approve this - provided that 1) there's SQE-OK and 2) the release team reviews and doesn't have any concerns. Please get SQE to review and mark with SQE-OK if they agree to this fix

This issue is _not_ fixed in hs24, only in hs25.

I think most of these tests are excluded by JDK-6326210

Any idea why testing failed to pick this up? :(