JDK-8029528

Thu Oct 31 12:14:29 UTC 2019

Is there anything in particular with this bug that motivates the extra work, or do you mean in general for all bugs like this?
/Jesper

> On 31 Oct 2019, at 10:16, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> 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
> 