RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm
tristan.yan at oracle.com
Tue Jan 14 12:40:52 UTC 2014
Okay. But I think we all agree we should at least bring this test back
for further tacking.
On 01/14/2014 10:39 AM, David Holmes wrote:
> 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.
> 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.
>> Thank you
>> 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
>>> 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.
More information about the core-libs-dev