JDK-8029528

[Lindenmaier, Goetz]

Hi,

you could open a new bug with the non-sensitive information.
Add the hidden bug as duplicate and close it.
Then reference the public bug in the exclude list.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of
> jesper.wilhelmsson at oracle.com
> Sent: Mittwoch, 30. Oktober 2019 19:08
> To: Severin Gehwolf <sgehwolf at redhat.com>
> Cc: jdk-dev <jdk-dev at openjdk.java.net>
> Subject: Re: JDK-8029528
> 
> > On 30 Oct 2019, at 17:22, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> >
> > Hi,
> >
> > Is there a good reason why JDK-8029528 isn't visible? It's a bug
> > referenced in ProblemList.txt[1] and I'd like to see some details. If
> > at all possible, could it be made public?
> >
> > Thanks,
> > Severin
> >
> > [1]
> http://hg.openjdk.java.net/jdk/jdk/file/2c3cc4b01880/test/hotspot/jtreg/Prob
> lemList.txt#l43
> 
> I've said it over and over, year after year, I've written it in our process
> documentation, I've communicated it through emails: Never ever put any
> confidential information in the description of a bug. Regardless if the bug
> concerns a closed feature or internal tests - at some point in the future we
> might want to open the bug. If I've had a dime for every time I was right I
> would finally get my first dime.
> 
> The bug was filed in 2013, it's about JFR which at the time was an Oracle
> internal feature. As JFR has been open sourced I'd be happy to open the bug,
> but the description of the bug contains confidential information (for no good
> reason, as always). There is no point in cleaning up the description since the old
> description will still be available in the history of the bug.
> 
> I'll share the bulk of the details below, let me know if you need more.
> 
> JDK-8029528 - compiler/ciReplay/TestSA.sh fails: Error while parsing line 1002:
> unknown command
> Type: Bug
> Priority: P5
> Affects: hs25, 8, 9, 10
> Fix version: tbd
> Conponent: hotspot / svc-sgent
> OS: linux (comment below indicate that this is not only linux though)
> 
> Description:
> This test failure was spotted in the 2013.12.03 RT_Baseline nightly
> 
> JDK: Java(TM) SE Runtime Environment 1.8.0 b118 (1.8.0-ea-fastdebug-b118)
> VM: Java HotSpot(TM) 64-Bit Server VM 25.0 b62 (25.0-b62-internal-
> 201312032153.sspitsyn.hotspot-fastdebug)
> 
> compiler/ciReplay/TestSA.sh
> 
> Tests fails because of the following error:
> 
> Warning: entry was unresolved in the replay data
> Warning: entry was unresolved in the replay data
> Warning: entry was unresolved in the replay data
> Warning: entry was unresolved in the replay data
> Warning: entry was unresolved in the replay data
> Error while parsing line 1002: unknown command
> 
> Error: java.lang.NullPointerException
> Failed on unknown command
> 
> Options: -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -
> XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M
> Hosts: Linux-amd64
> 
> 
> Relates to: JDK-8155219 - [TESTBUG] Rewrite compiler/ciReplay/TestVM.sh in
> java
> 
> Comments:
> 
> ILW=LMH=P5. Not a production feature. Intermittent. No known workaround.
> 
> This test is going to be rewritten in java by JDK-8155219, so, problem might be
> gone after that.
> 
> after rewriting to java, test(renamed) still fails:
> compiler/ciReplay/TestSAServer.java" Exception java.lang.AssertionError:
> CLHSDB wasn't run successfully: Warning! JS Engine can't start, some
> commands will not be available. hsdb> Opening core file, please wait...
> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a
> function in sa.js at line number ... javax.script.ScriptException: TypeError:
> sapkg.runtime.VM.getVM is not a function in sa.js at line number ... Exception
> in thread "main" java.lang.InternalError: ciMetadata does not appear to be
> polymorphic at
> sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(j
> dk.hotspot.agent...-internal/BasicTypeDataBase.java:...) at
> sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(jdk.ho
> tspot.agent...-internal/VirtualBaseConstructor.java:...) at
> sun.jvm.hotspot.utilities.GrowableArray.at(jdk.hotspot.agent...-
> internal/GrowableArray.java:...) at
> sun.jvm.hotspot.ci.ciEnv.dumpReplayData(jdk.hotspot.agent...-
> internal/ciEnv.java:...) at
> sun.jvm.hotspot.CommandProcessor$5.doit(jdk.hotspot.agent...-
> internal/CommandProcessor.java:...) at
> sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent...-
> internal/CommandProcessor.java:...) at
> sun.jvm.hotspot.CommandProcessor.executeCommand(jdk.hotspot.agent...-
> internal/CommandProcessor.java:...) at
> sun.jvm.hotspot.CommandProcessor.run(jdk.hotspot.agent...-
> internal/CommandProcessor.java:...) at
> sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent...-internal/CLHSDB.java:...) at
> sun.jvm.hotspot.CLHSDB.main(jdk.hotspot.agent...-internal/CLHSDB.java:...)
> 
> Here's the failures of this test that we're seeing in the 2017-08-04 JDK10-hs
> nightly:
> MacOS X failure:
> compiler/ciReplay/TestSAServer.java: Exception java.lang.InternalError:
> ciMetadata does not appear to be polymorphic
> Win-64 and Win32 failures:
> compiler/ciReplay/TestSAServer.java: Timeout
> 
> /Jesper