JDK-8029528

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