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:[EMAIL PROTECTED]
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:[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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]