JDK-8029528

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Oct 31 13:04:26 UTC 2019


Hi,

this could be a general way to deal with bugs you
can not make public.  Editing the text of the bug
is not possible as you are saying, but that is not the
only way to make such a bug public.

Also, us non-Oracle reviewers should watch out that no
closed bugs are mentioned in the ProblemLists. And 
maybe no closed bugs should be pushed, Oracle could
always open a "mirror-bug" just describing the problem 
and the fix.

And no, me personally, I'm not working on this special 
bug currently.

Best regrards,
  Goetz.


> -----Original Message-----
> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
> Sent: Donnerstag, 31. Oktober 2019 13:14
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Severin Gehwolf <sgehwolf at redhat.com>; jdk-dev <jdk-
> dev at openjdk.java.net>
> Subject: Re: JDK-8029528
> 
> 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
> >



More information about the jdk-dev mailing list