harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fedotov, Alexei A" <alexei.a.fedo...@intel.com>
Subject RE: [drlvm] [testing] Excluding commit tests until the problem is fixed
Date Mon, 16 Oct 2006 21:25:21 GMT
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:gshimansky@gmail.com]
>Sent: Tuesday, October 17, 2006 12:23 AM
>To: Fedotov, Alexei A
>Cc: geir@pobox.com; Ivan Volosyuk; Artem Aliev; Nikolay Kuznetsov;
harmony-
>dev@incubator.apache.org
>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:geir@pobox.com]
>> >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: harmony-dev-unsubscribe@incubator.apache.org
>> >For additional commands, e-mail:
harmony-dev-help@incubator.apache.org
>
>--
>Gregory Shimansky, Intel Middleware Products Division

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message