JDK-8029528 (original) (raw)

jesper.wilhelmsson at oracle.com jesper.wilhelmsson at oracle.com
Mon Nov 4 17:06:26 UTC 2019

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 RTBaseline 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