RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm
David Holmes
david.holmes at oracle.com
Tue Jan 14 02:39:08 UTC 2014
On 13/01/2014 4:21 PM, Tristan Yan wrote:
> Hi All
> I add more trace output to track down possible reason of this failure.
> Please help to review it again.
>
> http://cr.openjdk.java.net/~tyan/JDK-7027502/webrev.05/
You seem to have dragged in some unrelated changes to ProblemList.txt
Also I don't see much in the way of trace output. I see two potentially
useful printlns (and one unnecessary one). Further all the changes from
the static variables are still there but we already determined that they
should have no affect on the running of the test, nor did they explain
the failure mode.
So other than reenabling this test to see if it actually still fails, I
don't see the point of the functional changes.
Sorry.
David
> Thank you
> Tristan
>
> On 01/10/2014 07:20 AM, Tristan Yan wrote:
>> Hi David
>> I wasn't able to reproduce this failure either in local or in our same
>> binaries running(This is a continuous running with same JDK binaries).
>> So intention for this code change is bringing this test back; add
>> some debug info and try to avoid possible issues in this test. I agree
>> this code change won't solve the failure happened. But this test was
>> put into ProblemList two years ago better move for this is move out it
>> from ProblemList and trace down the issue in our normal nightly.
>> Thank you
>> Tristan
>>
>> On 01/10/2014 06:35 AM, David Holmes wrote:
>>> On 9/01/2014 10:14 PM, Alan Bateman wrote:
>>>> On 09/01/2014 11:27, David Holmes wrote:
>>>>>
>>>>> Okay I think I get it now. Both MonitorTest and WaitersTest use the
>>>>> Context class, so if both tests run in the same VM the second test
>>>>> will see the static total_turns_taken and "turn" in the state they
>>>>> were left from the first test - hence the second test will always
>>>>> fail. The bug report suggests making the tests othervm to avoid the
>>>>> problem but instead you have changed from using static state to
>>>>> instance state so that there is no interference.
>>>> I haven't been following this one closely but I thought that jtreg
>>>> created a class loader for each test (irrespective of mode) so I
>>>> wouldn't expect statics to be an issue.
>>>
>>> That aside DemoRun forks off its own JVM to run a given test anyway!
>>>
>>> So I don't understand how the proposed fixes could actually be
>>> addressing the hangs that are occurring. Even if the statics were
>>> being shared I don't see how that leads to the failure mode in the
>>> bug report.
>>>
>>> David
>>>
>>>> -Alan.
>>
>
More information about the core-libs-dev
mailing list