JDK-6201302 : AMD64: the dtrace ustack prints hexa-decimals for java frames
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2004-11-29
  • Updated: 2012-10-08
  • Resolved: 2004-12-18
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.
Other JDK 6
5.0u2Fixed 6 b16Fixed
Related Reports
Relates :  
JDK-6201298 - AMD64: the dtrace ustack prints hexa-decimals for java frames
Description
The dtrace ustack action prints hexa-decimal addresses instead of method
names for java frames.
Comments
EVALUATION jhelper.d uses uint32 type to read OFFSET_interpreter_frame_method. This value is negative for x86 and amd64. This offset becomes a huge positive value on AMD-64 and therefore we don't read correct methodOop from an interpreter frame. Due to this, hex value will be printed instead of correct method name. Why? Kernel sees all pointers as 32 bit on x86 and sparc and as 64 bit on AMD-64 and sparcv9. When adding an unsigned int to pointer, it promotes it to the pointer size. The program below prints different values when compiled with and without -xarch=v9. #include <stdio.h> void main() { int i = -5; /* %ld to print the value as long * which is 32 bit on sparc/x86 and 64 bit on sparcv9/amd-64. * On 32 bit, it prints -5, that explains why we didn't hit the problem * on x86. On 64 bit, it prints a large positive value. */ printf("%ld\n", (unsigned int) i); } The fix is to read negative valued offsets as type int32 instead of type uint32. Note that on sparc and sparcv9, all offsets are positive and hence we won't hit this problem there. ###@###.### 2004-12-01 13:53:01 GMT The following bug has to be fixed as well in order to build dtrace support (jstack or ustack supporting java frames) on amd64: CR 6201952: Solaris 10 AMD64 RE build machines must be S10 build 73 or newer (dtrace changes needed) http://bt2ws.central.sun.com/CrPrint?id=6201952 ###@###.### 2004-12-07 08:09:20 GMT
29-11-2004
WORK AROUND There is no workaround on Solaris amd64. ###@###.### 2004-12-02 07:38:09 GMT
29-11-2004
SUGGESTED FIX The src/os/solaris/dtrace/jhelper.d file must be fixed as follows: % sccs sccsdiff -r1.19 -r1.20 jhelper.d -c ------- jhelper.d ------- *** /tmp/geta8513 Wed Dec 1 23:28:25 2004 --- /tmp/getb8513 Wed Dec 1 23:28:25 2004 *************** *** 38,47 **** #define copyin_uchar(ADDR) *(uchar_t*) copyin((pointer) (ADDR), sizeof(uchar_t)) #define copyin_uint16(ADDR) *(uint16_t*) copyin((pointer) (ADDR), sizeof(uint16_t)) #define copyin_uint32(ADDR) *(uint32_t*) copyin((pointer) (ADDR), sizeof(uint32_t)) #define SAME(x) x #define copyin_offset(JVM_CONST) JVM_CONST = \ ! copyin_uint32(JvmOffsetsPtr + SAME(IDX_)JVM_CONST * sizeof(uint32_t)) int init_done; --- 38,48 ---- #define copyin_uchar(ADDR) *(uchar_t*) copyin((pointer) (ADDR), sizeof(uchar_t)) #define copyin_uint16(ADDR) *(uint16_t*) copyin((pointer) (ADDR), sizeof(uint16_t)) #define copyin_uint32(ADDR) *(uint32_t*) copyin((pointer) (ADDR), sizeof(uint32_t)) + #define copyin_int32(ADDR) *(int32_t*) copyin((pointer) (ADDR), sizeof(int32_t)) #define SAME(x) x #define copyin_offset(JVM_CONST) JVM_CONST = \ ! copyin_int32(JvmOffsetsPtr + SAME(IDX_)JVM_CONST * sizeof(int32_t)) int init_done; ###@###.### 2004-12-02 07:38:09 GMT
29-11-2004