JDK-7028172 : SA needs to adapt to Solaris libproc change made in 6748307
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs21
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2011-03-16
  • Updated: 2011-07-29
  • Resolved: 2011-05-16
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 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-7041586 - SOLARIS_11_B159_OR_LATER define should be removed from HotSpot when Solaris 11 is base build OS
Relates :  
JDK-7046405 - fix for 7028172 causes "sed: command garbled:" message
Relates :  
JDK-7043298 - fix for 7028172 causes "Label too long: ..." error message
Description
The following bug is fixed in Solaris Nevada B159:

    6748307 3/3 pstack(1) prints the wrong signal number with a signal
                handler frame for a 64-bit SPARC process

This bug makes minor changes to the libproc API that SA uses.

Here is the ARC link for the original interface:

    http://sac.sfbay/PSARC/2004/029/contract-01

More details will be added as we flesh out the possible impacts
of this API tweak.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/405c634f4aaa
04-05-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/405c634f4aaa
02-05-2011
SUGGESTED FIX See attached 7028172-webrev-cr0.tgz for the proposed fix.
02-05-2011
EVALUATION The changes to the libproc Pstack_iter() API are pretty straight forward. However, Java is a strange beast that is built on different OS versions and expected to run on the build OS and newer. So getting things to compile and run safely means jumping through loops. Here are the scenarios: - built on Nevada-B159 and later: - code compiles using newer API with no hoops (for simplicity, I have newer API as a wrapper around the older API because Java doesn't use any of the new parameters) - runs on Nevada-B159 and later so calls the newer API with no hoops - built on Nevada-B158 and earlier: - code compiles with newer API as a wrapper around the older API so both are available - checks the running OS and calls the newer API if running on Nevada-B159 or later. Calls the older API if running on Nevada-B158 or earlier So we'll have Makefile changes to detect building on Nevada-B159 and later which will cause -DSOLARIS_11_B159_OR_LATER to be specified on the compile line. We'll have a #ifdef SOLARIS_11_B159_OR_LATER check in the libproc.h header file for the newer version of proc_stack_f otherwise we'll define the older version of proc_stack_f. The client code that calls Pstack_iter() will have a a #ifdef SOLARIS_11_B159_OR_LATER check that will call Pstack_iter() with the newer version of proc_stack_f. Otherwise, the client code will detect the running OS and call Pstack_iter() with the newer version of proc_stack_f when running on Nevada-B159 or later or it will call Pstack_iter() with the older version of proc_stack_f when running on Nevada-B158 or earlier. The hoops we jump through for backward compatibility.
30-04-2011