JDK-8029528

[Lindenmaier, Goetz]

Hi,

I just saw that "8234267: DelegationPermission implementation doesn't completely follow the updated specification"
https://hg.openjdk.java.net/jdk/jdk/rev/18420160287b
was pushed with a closed bug. 

Is it possible to open this one up?

(Would it be possible to extend jcheck to reject closed bugs in jdk/jdk?)

Best regards,
  Goetz.

> -----Original Message-----
> From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com>
> Sent: Montag, 4. November 2019 18:06
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: Ioi Lam <ioi.lam at oracle.com>; jdk-dev at openjdk.java.net
> Subject: Re: JDK-8029528
> 
> We have an internal policy saying that any change in the open code should
> have an open JBS issue, so in theory there shouldn't be any reviews for closed
> issues on the open lists. If this is happening (enough to be a problem) I'd be
> happy to take that discussion internally, so please let me know.
> 
> As for closed bug ids in the problemList this is mainly the result of issues that
> was moved from closed problemList to open as part of opening different
> features like JFR, ZGC and others. These bugs should be opened a far as it is
> possible. I think creating a new open bug and close the old one as a duplicate is
> a good solution if the old bug can't be opened.
> 
> /Jesper
> 
> > On 4 Nov 2019, at 10:14, Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> wrote:
> >
> > Hi,
> >
> > If a fix for the closed bug is pushed under the "mirror" bug
> > in first place, no open source developer will ever run into
> > the bug id of the closed bug.  Similar for entries in the
> > ProblemLists.
> >
> > As reviews are in the open, reviewers could demand to
> > open a "mirror" bug before a change is pushed.
> >
> > Best regards,
> >  Goetz.
> >
> >> -----Original Message-----
> >> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Ioi Lam
> >> Sent: Donnerstag, 31. Oktober 2019 23:24
> >> To: jdk-dev at openjdk.java.net
> >> Subject: Re: JDK-8029528
> >>
> >> For this to work (smoothly), we would also need a mechanism that
> >> automatically redirects from the closed bug to the new "mirror" bug (for
> >> users that don't have access to closed bugs). Otherwise, you will still
> >> be staring at a "this bug is not accessible" page scratching your head.
> >>
> >> Thanks
> >> - Ioi
> >>
> >> On 10/31/19 6:04 AM, Lindenmaier, Goetz wrote:
> >>> 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
> >