harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Date Mon, 13 Nov 2006 12:51:02 GMT
On 10/26/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
>
> After H-1823 has been committed, I still see intermittent failures of
> drlvm kernel ThreadTest. Normally this test passes but today I got
> ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
> There is H-1789 for the first issue but it is not reprodiced with the
> attached test anymore. For the second test I filed H-1876 to make the test
> more stable. The patch has been committed recently but the test still may
> fail. I'd like someone to review the above mentioned tests to be sure they
> are correct otherwise we need to investigate failures and file JIRA's before
> the tests are exclued.
>

I looked at ThreadTest again and found one more incorrectness in
testGetStateBlocked(): it does not wait for the thread's run() method
actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 and
attached the patch. I ran the test more than 100 times and did not see a
failure.


> Vera, could you please review the tests?
>
>
>  On 10/26/06, Pavel Ozhdikhin <pavel.ozhdikhin@gmail.com> wrote:
> >
> > +1 to exclude failing tests for now and require that all remaining tests
> > must pass. Assuming some tests fail anyway cause people don't treat the
> > failures seriously. As soon as the bug causing the failure is fixed the
> > tests need to be unexcluded.
> >
> > Thanks,
> > Pavel
> >
> >
> > On 10/26/06, Rana Dasgupta <rdasgupt@gmail.com > wrote:
> > >
> > > The ideal way would be for acceptance tests like "build test" to
> > always
> > > pass
> > > and to catch and roll back the patch that breaks this invariant,
> > rather
> > > than
> > > to disable the tests. But I agree with Vera, it is important to keep a
> > > running set up as acceptance tests, so disabling the well known
> > failures
> > > may
> > > be the only way until we fix the problems.
> > >
> > > I don't know that any of the tests are "unstable". These are
> > > implementation
> > > bugs. gc.LOS is a bug in thread yielding by the apr Windows
> > functionality.
> > > The java.lang.ObjectTest also looks like an interpreter implementation
> > > error.
> > >
> > >
> > >
> > >
> > >
> > > > On 10/25/06, Volynets, Vera <vera.volynets@intel.com> wrote:
> > > > >
> > > > > Geir
> > > > > Some tests launched by command "build test" fail.
> > > > > The idea of  "build test" is to run it before each commit. In this
> > way
> > > > > you can catch regressions.
> > > > > In order to effectively catch regressions, i.e. tests that started
> > to
> > > > > fail after some change,
> > > > > it's necessary to have 'build test' pass in a stable way. One of
> > the
> > > > > ways to achieve stable state
> > > > > is to exclude failing tests or tests which show unstable behavior.
> > > > > So I analysed statistics of test runs on win ia32 platform and
> > made up
> > > a
> > > > > list of tests to be excluded:
> > > > > 1) smoke
> > > > > *** gc.LOS fails always on jitrino and interpreter, debug and
> > release
> > > > > 2) kernel
> > > > > *** java.lang.ClasssGenericsTest and
> > > > > *** java.lang.ClassGenericsTest4 fail because of timeout, so
> > > I  increase
> > > > > timeout in kernel.test.xml
> > > > > *** java.lang.ObjectTest fail on interpreter with following
> > message:
> > > > >     Testsuite: java.lang.ObjectTest
> > > > >     Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec
> > > > >     Testcase: testWait1(java.lang.ObjectTest): FAILED
> > > > >     An InterruptedException must be thrown in test thread!
> > > > >    junit.framework.AssertionFailedError: An InterruptedException
> > must
> > > be
> > > > > thrown in test thread!
> > > > >
> > > > > See HARNONY-1966 issue with attached patch.
> > > > >
> > > > >
> > > > > Vera Volynets
> > > > > Intel Middleware ProductsDivision
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
> --
> Thanks,
> Elena




-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message