On Tuesday 17 October 2006 00:13 Fedotov, Alexei A wrote: > We have mighty guys on this list. Why cannot we just fix these tests > instead of excluding them?
Because a test like gc.LOS hangs on windows for a month or more as far as I remember. AFAIK (excuse me if I missed something, I've caught up with emails skipping some) the problems come from APR implementation on windows, but I am not sure if there is a patch for APR to fix the problem. I hoped for a quick fix too because I don't like tests exclusion myself. But when the problem proves to be hard to solve it is better to put the test aside and have clean test runs to make development easier for everyone. > 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. > > 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] -- Gregory Shimansky, Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
