JDK-8029528

Ioi Lam ioi.lam at oracle.com
Thu Oct 31 22:24:17 UTC 2019


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



More information about the jdk-dev mailing list