JDK-8150986 : serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-03-01
  • Updated: 2020-09-01
  • Resolved: 2016-03-03
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 9 Other
9 b110Fixed openjdk8u262Fixed
Related Reports
Relates :  
Description
serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed in nightly build because of wrong file format (expected JAVA PROFILE 1.0.1 but found JAVA PROFILE 1.0.2).
Comments
Thanks. Reviewed and approved.
19-05-2020

OK. RFR: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011732.html
18-05-2020

Anything beyond automated path shuffling requires review. It may be overkill in some cases, but it's better to keep the rules simple to avoid confusion.
18-05-2020

No, I didn't think this was necessary. Test-only change, applies cleanly modulo copyright. Do we need a review for the copyright change? Here's a webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8150986/01/webrev/
13-05-2020

Has this been reviewed?
13-05-2020

Fix Request (OpenJDK 8u): Please approve backporting this test-only change to OpenJDK 8u in order to fix a new test failure in 8u252. Since JDK-8144732 got backported to 8u252 the test is now failing and a backport of this fix resolves it. Test fails prior, passes after. The JDK 9 patch applies cleanly post path-unshuffeling and manually fixing the copyright. Reject was: cat test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java.rej --- JMapHProfLargeHeapTest.java +++ JMapHProfLargeHeapTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it
17-04-2020

I believe this bug is caused by JDK-8129419 and hopefully Andreas can confirm that shortly. If the root cause is JDK-8129419, then this bug has already escaped to JDK9 back on 2016.02.10. Since JDK-8129419 was integrated so long ago, why is this failure mode only showing up now? Update: The failure was first spotted in the 2016-02-29 JDK9-hs-rt nightly. It did not fail in the 2016-02-26, 02-27 or 02-28 JDK9-hs-rt nightlies. Not sure why we were running nightly jobs on 02-27 and 02-28, but we did... Update: Verified that this test passed in the 2016-02-26 JDK9-hs-rt nightly for the Solaris X64 config; it failed in that config on 2016-02-29. Update: double checked my source history search and figured out that I identified the wrong changeset. This is the changeset that introduced the new message: changeset: 10320:36aaa9ceed16 user: aeriksso date: Fri Feb 26 16:28:42 2016 +0100 summary: 8144732: VM_HeapDumper hits assert with bad dump_len and that changeset was pushed on 2016-02-29 so now it all makes much more sense... Update: Just to be clear, the 'integration_blocker' label needs to stay since this failure mode has not escaped JDK9-hs-rt.
02-03-2016

Looks like the header was changed via this changeset: changeset: 9974:6bfa2b373a42 user: aeriksso date: Tue Jan 19 10:02:22 2016 +0100 summary: 8129419: heapDumper.cpp: assert(length_in_bytes > 0) failed: nothing to copy Update: I pasted the wrong changeset info here. See below... I removed the link to JDK-8129419.
02-03-2016

This is almost certainly because of JDK-8144732, where we stopped using format 1.0.1 Test will need to be updated, I missed it in my change - my bad.
02-03-2016

Andreas, can you take a look at this bug?
02-03-2016