Hello Gregory, I'm ok to exclude the tests. From the other side I believe we can achieve a fair progress against deadlocks just by applying patches http://issues.apache.org/jira/browse/HARMONY-1741 (understood), http://issues.apache.org/jira/browse/HARMONY-1823 (tried).
There is also a Windows-specific patch at http://issues.apache.org/jira/browse/HARMONY-1669 which can result in deadlock, though I haven't tried it myself yet. With best regards, Alexei Fedotov, Intel Java & XML Engineering >-----Original Message----- >From: Gregory Shimansky [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 17, 2006 12:23 AM >To: Fedotov, Alexei A >Cc: [EMAIL PROTECTED]; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov; harmony- >[EMAIL PROTECTED] >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is >fixed > >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]
