RFR (trivial) 8208074: [TESTBUG] vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java failed with NullPointerException
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue Jul 31 20:09:20 UTC 2018
On 7/31/18 2:07 PM, serguei.spitsyn at oracle.com wrote:
> On 7/31/18 09:13, Chris Plummer wrote:
>> On 7/31/18 5:06 AM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 7/31/18 3:29 AM, serguei.spitsyn at oracle.com wrote:
>>>> Hi Chris,
>>>>
>>>> Good catch.
>>>> It is possible that this webrev does not fix the JDK-8202896.
>>>> The JDK-8202896 is about timeouts which are normally intermittent
>>>> (is it right?).
>>>>
>>>> There are two options here:
>>>> A: close 8202896 as a dup of 8208074
>>>> B: keep the test problem listed and labeled with 8202896
>>>>
>>>> Let's wait for Coleen's answer.
>>>
>>> I closed https://bugs.openjdk.java.net/browse/JDK-8206076 (timeouts
>>> with -Xcomp)
>>> as a duplicate of
>>> https://bugs.openjdk.java.net/browse/JDK-8203820 (where I took
>>> InMemoryCompiler out of the threads)
>>> because that's where the attempted fix was.
>>>
>>> I think
>>> https://bugs.openjdk.java.net/browse/JDK-8202896 (getting Too many
>>> open files intermittently)
>>> should be closed as a duplicate too because it's the same root cause.
>>>
>>> And this one:
>>> https://bugs.openjdk.java.net/browse/JDK-8208074 (broken fix)
>>> fixes my fix and will remove the test from the ProblemList.txt.
>>>
>>> I believe it should be removed fromt he problem list because I don't
>>> think it will time out or intermittently fail again for the same
>>> reason. If it times out or fails for a different reason, we should
>>> file a whole new bug, with that specific analysis.
>>>
>>> Thanks,
>>> Coleen
>>
>> Hi Coleen,
>>
>> That all sounds reasonable. Thanks for cleaning up the bug situation.
>
> +1
Thanks Chris and Serguei for your discussion of this bug. Hopefully
this test becomes stable and useful now.
Coleen
>
> Thanks,
> Serguei
>>
>> Chris
>>>
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>> On 7/31/18 00:16, Chris Plummer wrote:
>>>>> Sorry, I thought this had been pushed already, but it hasn't. But
>>>>> it still looks like JDK-8202896 should be closed as a dup, and
>>>>> it's unclear to me if JDK-8206076 has been fixed and this test can
>>>>> be removed from the problem list.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 7/30/18 6:34 PM, Chris Plummer wrote:
>>>>>> Hi Coleen,
>>>>>>
>>>>>> Now that this had been pushed, I assume JDK-8202896 should be
>>>>>> closed as a dup. And what about JDK-8206076? Is it fixed by this
>>>>>> change also?
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On 7/30/18 1:49 PM, coleen.phillimore at oracle.com wrote:
>>>>>>> Summary: fixed refactoring caused by JDK-8203820
>>>>>>>
>>>>>>> open webrev at
>>>>>>> http://cr.openjdk.java.net/~coleenp/8208074.01/webrev
>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8208074
>>>>>>>
>>>>>>> Ran the test in mach5 on all Oracle supported platforms. Also
>>>>>>> took the test out of ProblemList.txt because JDK-8203820 fixes
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8202896.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Coleen
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
More information about the hotspot-runtime-dev
mailing list