JDK-6204559 : HPROF: HAT thinks the timestamp in the format=b file is bad
  • Type: Bug
  • Component: tools
  • Sub-Component: hprof
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2004-12-06
  • Updated: 2011-02-16
  • Resolved: 2005-09-30
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 6
6 b55Fixed
Related Reports
Relates :  
Relates :  
Description
Solaris SPARC 10_b72 & Solaris 9 
Java 5.0_b64 (GA)
HAT 1.1

I run:
$ ./java -Xrunhprof:file=dump.hprof,format=b -jar SwingSet2.jar

then

$ ./hat <path>/dump.hprof

The "Dump file created" date is very wrong.

$ date
Mon Dec  6 17:50:09 GMT 2004

HAT reports: Dump file created Thu Apr 13 01:33:08 BST 1989

$ ls -l
   4179207 Dec  6 16:11 dump.hprof


###@###.### 2004-12-06 17:58:07 GMT
###@###.### 2004-12-06 18:00:58 GMT
###@###.### 2004-12-06 18:06:15 GMT

Comments
EVALUATION The jlong arithmetic appeared to be the problem, should be fixed now.
20-09-2005

SUGGESTED FIX jlong arithmetic should not assume promotions, add (jlong) casts.
14-09-2005

EVALUATION I think this has to do with the jlong or 'long long' bugs in the Sun C compiler. I was indeed getting bogus time values, but when I re-structured the jlong arithmetic to force casts in all places, it seems to be working better. Also switched to gettimeofday() on Solaris for this time stamp.
14-09-2005

EVALUATION I'm not seeing anything obvious in the code where this is broken. Still investigating. Could be a Solaris problem, but can't find any evidence that any remaining gethrtimne problems remain in Solaris 10. Hprof is using gethrtime for the time of day, and this may be wrong, but the number should not be that far off. Should probably switch this to gettimeofday() so that the proper DST is used. ###@###.### 2004-12-15 19:16:15 GMT Please let me know if anyone sees this happening with Solaris 10 Build 74. ###@###.### 2005-1-12 22:46:23 GMT I need some automatic HAT regression tests. So far I have not been able to reproduce this timestamp problem just the different problems, which I will file a separate bug for. I will convert to gettimeofday, but I'm not convinced this has anything to do with the problem. The description says it's happening on Solaris 9 too, so that seems to rule out any Solaris 10 regression in my mind. ###@###.### 2005-2-23 00:31:58 GMT
06-12-2004