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 :  
Description
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.

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

Comments
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.
02-07-2013

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...
02-07-2013

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?
02-07-2013

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!
02-07-2013

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
20-06-2013

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

SQE-OK Ingemar ��berg, SQE
20-06-2013

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.)
20-06-2013

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
19-06-2013

This issue is _not_ fixed in hs24, only in hs25.
13-06-2013

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

Any idea why testing failed to pick this up? :(
16-10-2012