On 10/17/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
We have mighty guys on this list. Why cannot we just fix these tests instead of excluding them? I suggest starting with basic threading issues such as org.apache.harmony.luni.tests.java.lang.ThreadTest, org.apache.harmony.luni.tests.java.lang.ThreadGroupTest - they reliably fail in my environment. I volunteer for checking reliability of fixes.
The ThreadTest fails stabily due to HARMONY-1789 and intermittently due to HARMONY-1876 (the test's problem). I've never seen the ThreadGroupTest failure. Gregory asked why this test fails on RI too. It looks like the RI implementation of Thread.destroy() and ThreadInterrupt() for new, terminated and current thread contradicts the spec. RI failures on getState() look unexpected. I'll look at the test. With best regards,
Alexei Fedotov, Intel Middleware Products Division >-----Original Message----- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 17, 2006 12:01 AM >To: harmony-dev@incubator.apache.org >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is >fixed > > > >Gregory Shimansky wrote: >> Hello >> >> After reading several threads about drlvm tests failing for quite a while >I >> decided we need to exclude them temporarily until the bugs are fixed. >When on >> test fails, it means that other are not run after it because drlvm has >> several sets of tests which run in different modes, so there are many >test >> runs in one "build test" command. When some test doesn't work for quite >some >> time it means that other may not be ran for this period and we can get >more >> failures accidently. > >That's actually not true. I never commit unless all tests (minus some >kernel tests) run. > >The Finalizer and PhanRefQueueTest are flakey - I always repeat until >the passed, so the rest could run. I'm just sick of it, so i did the >magic @keyword attribute and committed. > >> >> Excluding tests is not good, but not running some basic commit checks is >> worse, so I think we need to disable them until the bugs are fixed. So >far I >> know about 3 tests which fail for sure: >> >> gc.LOS - stably hangs on windows XP >> gc.Finalizer and gc.PhantomReferenceQueue - fail because of incorrect CCE >> condition detected, fail with rate less than 100%. Ok I've just read that >> Geir has excluded them already >> >> Are there any other tests which don't work perfectly to do a clean tests >run? >> I think we need it do make minimal commit checks for drlvm. >> >> I've seen java.lang.ThreadTest in kernel tests to output something that >it has >> failed on reference JRE. Is this test correct if it doesn't work on RI? >The >> failure however doesn't seem to make test run to fail so maybe we could >leave >> this test for now. >> >> I also have a question about 15 smoke tests excluded with XXX or X_int >> keywords. They've been disabled since I remember. Is there any reason why >> they aren't included in test runs? > >I tried to put some back. StackTest still doesn't work. It's hard to >believe... so I gave up and just kept going :) > >geir > >> > >--------------------------------------------------------------------- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Thanks, Elena
