JDK-8029528

Fri Nov 8 16:26:06 UTC 2019

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