Elena Semukhina wrote:
On 11/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> Elena Semukhina wrote:
>> > As Gregory mentioned ThreadTest.testJoinlongint() failure he
observed
>> > yesterday, I filed a
On 11/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>
>> Elena Semukhina wrote:
>> > As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
>> > yesterday, I filed a
http://issues.apache.org/
Elena Semukhina wrote:
On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
> yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
> issue
> for that. I saw this failure quite l
On 11/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
> yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
> issue
> for that. I saw this failure quite long ago but cannot repro
Elena Semukhina wrote:
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204
issue
for that. I saw this failure quite long ago but cannot reproduce it today
trying different platforms/EMs. When the test faile
As Gregory mentioned ThreadTest.testJoinlongint() failure he observed
yesterday, I filed a http://issues.apache.org/jira/browse/HARMONY-2204 issue
for that. I saw this failure quite long ago but cannot reproduce it today
trying different platforms/EMs. When the test failed, it reported that
actual
Thank you, Gregory!
On 11/15/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> I've found one more issue in the kernel ThreadTest. Filed
> https://issues.apache.org/jira/browse/HARMONY-2193.
>
> Alexey, please take a look!
I am not an Alexey, but I assigned this JIRA to
Elena Semukhina wrote:
I've found one more issue in the kernel ThreadTest. Filed
https://issues.apache.org/jira/browse/HARMONY-2193.
Alexey, please take a look!
I am not an Alexey, but I assigned this JIRA to myself. The testcase
seems to be working both on linux and windows, I committed the
I've found one more issue in the kernel ThreadTest. Filed
https://issues.apache.org/jira/browse/HARMONY-2193.
Alexey, please take a look!
On 11/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
> On Monday 13 November 2006 15:51 Elena Semukhin
2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> > drlvm kernel ThreadTest. Normally this test passes but
On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > After H-1823 has been committed, I still see intermittent failures of
> > drlvm kernel ThreadTest. Normally this test passes but today I got
> > ThreadTest.testInterrupt_Sleeping()
On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
After H-1823 has been committed, I still see intermittent failures of
drlvm kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first i
HI,
Do we have strong reasons to run all kernel tests in three different
modes before commit? Probably, it makes sense to choose two or three
most powerful tests and include them to smoke?
Evgueni
On 11/12/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
In addition to excluding some tests, I would
In addition to excluding some tests, I would suggest removing
smoke/classloader/ClassTestGetDeclaringClass as it is exact copy of kernel
test with the same name.
Also, smoke/classloader/ExceptionInInitializerTest must be returned to
acceptance runs.
Pavel.
On 10/25/06, Volynets, Vera <[EMAIL PRO
I'll check on 1830. Somehow the JIRA dropped my comments! I was debugging on
Windows since that was the original bug report.
An exception may be OK, since this is a resource intensive test, but it
should not crash when handling the exception. That part should have been
fixed. Also, we need to see
Rana Dasgupta wrote:
Hi,
I did not want to start a new thread for this. Could someone please close
JIRA issues 1109, 1662, 1830? These have been fixed by recent changes in
the
stack and exception handling. In any case, none of them repro. Comments on
teh JIRA.
I closed 1109 and 1162, but
Hi,
I did not want to start a new thread for this. Could someone please close
JIRA issues 1109, 1662, 1830? These have been fixed by recent changes in the
stack and exception handling. In any case, none of them repro. Comments on
teh JIRA.
Thanks,
Rana
On 10/25/06, Volynets, Vera <[EMAIL PROTE
27.10.06, Salikh Zakirov<[EMAIL PROTECTED]> написал(а):
Gregory Shimansky wrote:
>> But on Linux these tests fail with
>> lost of different exceptions:
>>
>> For java.lang.ClassGenericsTest:
>>
>> java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z
>> java.lang.NoClassDefFou
Gregory Shimansky wrote:
>> But on Linux these tests fail with
>> lost of different exceptions:
>>
>> For java.lang.ClassGenericsTest:
>>
>> java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z
>> java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z
>> java.lang.
Gregory Shimansky wrote:
Ok I think I've found the cause of problems with these two tests on
Linux which I had yesterday. On Gentoo I have russian locale set
"ru_RU.KOI8-R" while on all other Linux installations it appears there
are various combinations of *.UTF-8 locales (usually "en_US.UTF-
Gregory Shimansky wrote:
2) kernel
*** java.lang.ClasssGenericsTest and
*** java.lang.ClassGenericsTest4 fail because of timeout, so I increase
timeout in kernel.test.xml
These tests work for me on Windows. But on Linux these tests fail with lost of
different exceptions:
For java.lang.Class
No argument from me. But we've never passed all, and would love to do so.
Much recent work has been trying to get to that point, and we did accept
the disruption of TM and Invocation API patches, with the idea to decide
to commit and then fix after to make progress.
geir
Rana Dasgupta wrote
Volynets, Vera wrote:
Geir
Some tests launched by command "build test" fail.
The idea of "build test" is to run it before each commit. In this way you can
catch regressions.
Yes, that is what I do
In order to effectively catch regressions, i.e. tests that started to fail
after some chang
Great - thanks!
Note that Salikh has offered an alternative - can you take a look?
Evgueni Brevnov wrote:
The reason of gc.Free failure was identefied. Thanks to Salikh and
Ivan! Here is the patch
http://issues.apache.org/jira/browse/HARMONY-1978
Thanks
Evgueni
On 10/26/06, Elena Semukhina <[
The reason of gc.Free failure was identefied. Thanks to Salikh and
Ivan! Here is the patch
http://issues.apache.org/jira/browse/HARMONY-1978
Thanks
Evgueni
On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> Elena Semukhina wrote
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Elena Semukhina wrote:
> After H-1823 has been committed, I still see intermittent failures of
drlvm
> kernel ThreadTest. Normally this test passes but today I got
> ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
Elena Semukhina wrote:
After H-1823 has been committed, I still see intermittent failures of drlvm
kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first issue but it is not reprodiced with
increases
PASSED
Evgueni
On 10/26/06, Volynets, Vera <[EMAIL PROTECTED]> wrote:
>
>
> -Original Message-
> From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 26, 2006 10:18 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [drlvm][test]
dikhin [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 10:18 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][test]Exclude some tests from "build test" target,
make 'build test' pass
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>
> O
-Original Message-
From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 10:18 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm][test]Exclude some tests from "build test" target,
make 'build test' pass
On 10/26/06, Grego
After H-1823 has been committed, I still see intermittent failures of drlvm
kernel ThreadTest. Normally this test passes but today I got
ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures.
There is H-1789 for the first issue but it is not reprodiced with the
attached test anymo
+1 to exclude failing tests for now and require that all remaining tests
must pass. Assuming some tests fail anyway cause people don't treat the
failures seriously. As soon as the bug causing the failure is fixed the
tests need to be unexcluded.
Thanks,
Pavel
On 10/26/06, Rana Dasgupta <[EMAIL
On 10/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Wednesday 25 October 2006 21:05 Rana Dasgupta wrote:
> The ideal way would be for acceptance tests like "build test" to always
> pass and to catch and roll back the patch that breaks this invariant,
> rather than to disable the tests.
On Wednesday 25 October 2006 21:05 Rana Dasgupta wrote:
> The ideal way would be for acceptance tests like "build test" to always
> pass and to catch and roll back the patch that breaks this invariant,
> rather than to disable the tests. But I agree with Vera, it is important to
> keep a running se
On Wednesday 25 October 2006 20:29 Volynets, Vera wrote:
> Geir
> Some tests launched by command "build test" fail.
> The idea of "build test" is to run it before each commit. In this way you
> can catch regressions. In order to effectively catch regressions, i.e.
> tests that started to fail afte
The ideal way would be for acceptance tests like "build test" to always pass
and to catch and roll back the patch that breaks this invariant, rather than
to disable the tests. But I agree with Vera, it is important to keep a
running set up as acceptance tests, so disabling the well known failures
36 matches
Mail list logo
