JDK-8029528 (original) (raw)

Langer, Christoph christoph.langer at sap.com
Fri Nov 8 20:54:13 UTC 2019

That's great, then I can simply backport the change to jdk11 without having to create a new bug. Thanks a lot, Jesper.

-----Original Message----- From: jesper.wilhelmsson at oracle.com <jesper.wilhelmsson at oracle.com> Sent: Freitag, 8. November 2019 17:26 To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com> Cc: Ioi Lam <ioi.lam at oracle.com>; jdk-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com> Subject: Re: JDK-8029528

JDK-8224505 has been opened now. /Jesper > On 8 Nov 2019, at 09:45, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote: > > Hi Jesper, > > that's just what I proposed, great! > ... obviously not that easy to execute, see JDK-8224505. > > 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 >>>>> 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 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.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 >>> >

More information about the jdk-dev mailing list