RFR for JDK-7027502: Test failures in demo/jvmti/hprof testcases, need to be othervm
tristan.yan at oracle.com
Mon Jan 13 06:21:05 UTC 2014
I add more trace output to track down possible reason of this failure.
Please help to review it again.
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