harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] [testing] Excluding commit tests until the problem is fixed
Date Mon, 16 Oct 2006 23:26:13 GMT
So since I don't have Win 2003, I gotta just commit and let someone else 
test?

Any committer have win 2003?

Fedotov, Alexei A wrote:
> Sorry for my English - 
> 
> http://issues.apache.org/jira/browse/HARMONY-1669
> Artem told this patch fixes a deadlock on Windows.
> 
> I haven't tried the fix. As far as I understand we put SuspendThread()
> check and ResumeThread() action under one critical section when trying
> to flush memory. It's ok not to risk the integrity of the whole
> operation.
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geir@pobox.com]
>> Sent: Tuesday, October 17, 2006 1:30 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
>> fixed
>>
>>
>>
>> Fedotov, Alexei A wrote:
>>> 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).
>> Maybe - i tried 1823 and didnt' see the failure.  I'll look at both
> again.
>>> 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.
>> Do you mean the fix results in deadlock?  or the fix fixes the
> deadlock?
>> geir
>>
>>> 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
>> ---------------------------------------------------------------------
>> 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
> 
> ---------------------------------------------------------------------
> 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
> 

---------------------------------------------------------------------
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