Open code changes with closed JBS issue - was : RE: JDK-8029528

Langer, Christoph christoph.langer at sap.com
Thu Feb 13 13:24:28 UTC 2020


Hi,

maybe - when project Skara gets enabled for jdk/jdk, we can have a check that bugs have to be open before push? And in case they can't be opened, a shadow bug would have to be created. Would that be feasible?

Best regards
Christoph

> -----Original Message-----
> From: jdk-dev <jdk-dev-bounces at openjdk.java.net> On Behalf Of Baesken,
> Matthias
> Sent: Donnerstag, 13. Februar 2020 14:08
> To: Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
> Cc: jdk-dev at openjdk.java.net
> Subject: [CAUTION] RE: Open code changes with closed JBS issue - was : RE:
> JDK-8029528
> 
> Thanks,   11 bugs opened is a good start  !
> 
> >  I'm still waiting for feedback on a
> > few more that I hope can be opened and then there's a few that
> > unfortunately can't be opened.
> 
> Lets hope you can open a few more .
> 
> Best regards, Matthias
> 
> 
> >
> > * PGP Signed: 13.02.2020 at 14:01:05
> >
> > Hi Matthias.
> >
> > 11 bugs from the list has been opened now. I'm still waiting for feedback on
> a
> > few more that I hope can be opened and then there's a few that
> > unfortunately can't be opened.
> >
> > Cheers,
> > /Jesper
> >
> > > On 5 Feb 2020, at 08:50, Baesken, Matthias
> <matthias.baesken at sap.com>
> > wrote:
> > >
> > >
> > > Thanks !
> > >
> > > Hopefully you can open up at least a few of those .
> > >
> > >
> > > Best regards, Matthias
> > >
> > >
> > >>
> > >> Hi Matthias.
> > >>
> > >> That was more than one bug :-)   We are investigating these. I'll get back
> > to
> > >> you.
> > >> /Jesper
> > >>
> > >>> On 3 Feb 2020, at 13:03, Baesken, Matthias
> > <matthias.baesken at sap.com>
> > >> wrote:
> > >>>
> > >>>> We have an internal policy saying that any change in the open code
> > should
> > >>>> have an open JBS issue,
> > >>>
> > >>> Hello  Jesper,  we noticed again quite a few open changes , where
> > >> unfortunately  the related  bug is closed.
> > >>> Can you open  up    at least some of   those  bugs  ?
> > >>>
> > >>>
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8208080
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8207334
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8209622
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8163083
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8169718
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8193879
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8214418
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8205360
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8207938
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8223052
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8222548
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8223585
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8219781
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8221967
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8221121
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8213516
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8225182
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8225789
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8223727
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8226653
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8222751
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8191169
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8217997
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8223326
> > >>>
> > >>> https://bugs.openjdk.java.net/browse/JDK-8233801
> > >>>
> > >>>
> > >>> Thanks and best regards, Matthias
> > >>>
> > >>>
> > >>>>
> > >>>> 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/Pr
> > >>>> ob
> > >>>>>>>>>> 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.findDynamicTypeForAddres
> > >>>> s(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
> > >>>>>
> > >>>
> > >>
> > >>
> > >> * Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
> > >> * 0x769E782A
> >
> >
> > * Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
> > * 0x769E782A


More information about the jdk-dev mailing list