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