RFR (trivial) 8208074: [TESTBUG] vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java failed with NullPointerException
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Tue Jul 31 22:55:39 UTC 2018
On 7/31/18 13:09, coleen.phillimore at oracle.com wrote:
>
>
> 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.
Thanks a lot for taking care about this issue, Coleen!
Thanks,
Serguei
> 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 serviceability-dev
mailing list