You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ligang Wang <wa...@gmail.com> on 2008/09/08 04:48:11 UTC
Re: [testing] first M7 candidate (r681495) testing status
Sian, I looked at the Throwable.initCause() problem and agree with you.
My observation on this issue is as follows.
DRLVM implementation of Throwable.initCause():
public Throwable initCause(Throwable initialCause) {
if (initialCause == this) {
throw new IllegalArgumentException("A throwable cannot
be its own cause.");
}
// second call of initCause(Throwable)
if (cause != this) {
throw new IllegalStateException("A cause can be set at
most once." +
" Illegal attempt to re-set the cause of " + this);
}
cause = initialCause;
return this;
}
Firstly "this" is assigned to the private member "cause".
CLASSLIB implementation of Throwable.initCause():
public synchronized Throwable initCause(Throwable throwable) {
if (cause == this) {
if (throwable != this) {
cause = throwable;
return this;
}
throw new IllegalArgumentException("Cause cannot be the
receiver");
}
throw new IllegalStateException("Cause already initialized");
}
Firstly "this" is assigned to the private member "cause".
The description of of JavaDoc of Throwable.initCause():
public Throwable<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html>
*initCause*(Throwable<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html>
cause)
Initializes the *cause* of this throwable to the specified value. This
method can be called at most once.
*Throws:*
IllegalArgumentException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalArgumentException.html>-
if
cause is this throwable. (A throwable cannot be its own cause.)
IllegalStateException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalStateException.html>-
if this throwable was created with
Throwable(Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#Throwable(java.lang.Throwable)>or
Throwable(String,Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#Throwable(java.lang.String,
java.lang.Throwable)>, or this method has already been called on this
throwable.
The first exception is thrown when "cause" parameter is "this", and the
second exception is thrown when "causce", the instance member, is set for
the second time. From the description of JavaDoc, we can see there is an
overlap between the two exceptions. If initCause is called for the second
time and "cause" parameter is "this", which exception will be thrown?
JavaDoc doesn't have clear description on this. The DRLVM implementation
throws the first exception, while the CLASSLIB implementation throws the
second. We can not tell which is better.
But as Sian said, JavaDoc for ServerCloneException says that "Invoking the
method Throwable.initCause(Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#initCause(java.lang.Throwable)>on
an instance of
ServerCloneException always throws
IllegalStateException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalStateException.html>".
With this statement, we may see the CLASSLIB implementation is better. I
have modified ServerCloneExceptionTest.test_Constructor_String() and
Throwable.initCause() accordingly. The related JIRA issue is
https://issues.apache.org/jira/browse/HARMONY-5971.
Thanks,
Ligang
On Wed, Aug 13, 2008 at 6:50 PM, Sian January <si...@googlemail.com>wrote:
> Oliver has helped me track this down this morning, and it's occuring
> because there are differences between the versions of
> Throwable.initCause(..) in luni and in DRLVM. According to the spec,
> I think the test should be changed to check for IllegalStateException
> instead of IllegalArgumentException and then I think the version of
> Throwable in DRLVM should be changed to behave the same as the one in
> luni. However I don't think this is a big deal for M7 because I don't
> think it's very serious and it's not a regression since M6. What does
> anyone else think?
>
> Sian
>
> On 13/08/2008, Sian January <si...@googlemail.com> wrote:
> > I think the code is right and the test is wrong here, because the
> > Javadoc for ServerCloneException says that "Invoking the method
> > Throwable.initCause(Throwable) on an instance of ServerCloneException
> > always throws IllegalStateException."
> >
> > What is really confusing me is how this can be passing for anyone
> > else... The exclude list hasn't changed recently and I don't see how
> > it could be VM dependent either.
> >
> >
> > On 13/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > On Tue, Aug 12, 2008 at 10:18 AM, Sian January
> > > <si...@googlemail.com>wrote:
> > >
> > > > I am not seeing the management failures on my local (Windows)
> machine,
> > > > but I'm seeing an rmi failure:
> > > >
> > > >
> > > >
> org.apache.harmony.rmi.server.ServerCloneExceptionTest.test_Constructor_String
> > > > Cause already initialized
> > > > java.lang.IllegalStateException: Cause already initialized
> > > > at java.lang.Throwable.initCause(Throwable.java:293)
> > > > at
> > > >
> org.apache.harmony.rmi.server.ServerCloneExceptionTest.test_Constructor_String(ServerCloneExceptionTest.java:70)
> > > > at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > >
> > >
> > > This test [1] is creating an exception and then passing itself into
> > > 'initCause', which should throw IllegalArgumentException. Looking at
> the
> > > code though, it does look like there's a bug, as 'null' is being passed
> to
> > > the super() constructor, which will mess up Throwable, since it
> initializes
> > > 'cause' to 'this', so Throwable will think the cause is already set.
> > >
> > > Did this test recently get removed from an exclusion list?
> > >
> > >
> > > [1]
> > >
> http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/rmi/src/test/api/java/org/apache/harmony/rmi/server/ServerCloneExceptionTest.java?view=annotate
> > >
> > > >
> > > >
> > > > and an intermittent failure in java.net:
> > > >
> > > >
> > > >
> org.apache.harmony.luni.tests.java.net.URLConnectionTest.test_getInputStream
> > > >
> > > > Error receiving content coded data:
> > > > junit.framework.AssertionFailedError: Error receiving content coded
> data:
> > > > at
> tests.support.Support_HttpTests.runTests(Support_HttpTests.java:15)
> > > > at
> > > >
> org.apache.harmony.luni.tests.java.net.URLConnectionTest.test_getInputStream(URLConnectionTest.java:632)
> > > > at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > >
> > > > Is anyone else seeing these?
> > > >
> > > > Sian
> > > >
> > > > On 12/08/2008, chunrong lai <ch...@gmail.com> wrote:
> > > > > Thanks.
> > > > > I think the standard scripts produce that site although I always
> added
> > > > > publish/e-mail notification setup before install/run the test
> suites.
> > > > > It is understandable that some tests in classlib-test and
> drlvm-test
> > > > get
> > > > > failing report. We just need to understand the failures.
> > > > > As reported in M6,
> > > > > org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest,
> > > > >
> > > >
> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> > > > > etc fail classlib-test.
> > > > > Also we observed that java.lang.ClassGenericsTest.test_2
> sometimes fail
> > > > > drlvm-test.
> > > > > Another timeout issue of drlvm-test comes from
> > > > > thread.SmallStackThreadTest_jit, as discussed in HARMONY-4601, the
> test
> > > > case
> > > > > may run very slow when system resource is tight and finally
> introduce a
> > > > > timeout. Re-running the suite generally fixes the timeout.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 8/12/08, Nathan Beyer <nd...@apache.org> wrote:
> > > > > >
> > > > > > It's the tests that are failing - both classlib-test and
> drlvm-test.
> > > > > >
> > > > > > What's the specific integrity setup that's being used for that
> site?
> > > > Does
> > > > > > the standard out-of-the-box buildtest scripts produce that site?
> > > > > >
> > > > > > -Nathan
> > > > > >
> > > > > > On Mon, Aug 11, 2008 at 9:05 PM, chunrong lai <
> chunronglai@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > hi, Nathan:
> > > > > > > Steps to run testing cycle are listed in
> > > > > > > http://harmony.apache.org/subcomponents/buildtest/index.html.
> One
> > > > > > > integrity
> > > > > > > testing example is
> > > > > > >
> > > >
> http://harmony.apache.org/subcomponents/buildtest/howto.html#Extended.
> > > > > > > What is the error message you met (in what step)? What is
> the
> > > > > > content
> > > > > > > of the framework.local.properties file? I think that will help
> to
> > > > figure
> > > > > > > out
> > > > > > > the problem.
> > > > > > >
> > > > > > >
> > > > > > > On 8/12/08, Nathan Beyer <nd...@apache.org> wrote:
> > > > > > > >
> > > > > > > > What's being used to produce the integrity tests? I have an
> x86_64
> > > > > > Linux
> > > > > > > > box
> > > > > > > > that I can dedicate to testing. I've tried just using
> buildtest
> > > > with
> > > > > > > > 'classlib,drlvm,classib-test,drlvm-test', but I haven't
> gotten a
> > > > clean
> > > > > > > pass
> > > > > > > > yet.
> > > > > > > >
> > > > > > > > -Nathan
> > > > > > > >
> > > > > > > > On Mon, Aug 11, 2008 at 12:26 PM, chunrong lai <
> > > > chunronglai@gmail.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Hi, all:
> > > > > > > > >
> > > > > > > > > Here is r681495 snapshot testing status:
> > > > > > > > >
> http://people.apache.org/~chunrong/snapshots/r681495/index.html<
> http://people.apache.org/%7Echunrong/snapshots/r681495/index.html>
> > > > <
> > > > > >
> http://people.apache.org/%7Echunrong/snapshots/r681495/index.html>
> > > > > > > <
> > > > > > > >
> http://people.apache.org/%7Echunrong/snapshots/r681495/index.html
> > > > >.
> > > > > > > > > I am using
> > > > > > > > > two platforms (Linux x86, windows x86_64) at the moment.
> > > > Hopefully we
> > > > > > > > will
> > > > > > > > > have other two platforms in future for M8. Well, although
> we are
> > > > > > > testing
> > > > > > > > > only two platforms for M7, my experience is that the status
> for
> > > > > > another
> > > > > > > > two
> > > > > > > > > platforms should be not worse or just include some extra
> > > > intermittent
> > > > > > > > > errors
> > > > > > > > > which can be investigated in some later stages.
> > > > > > > > >
> > > > > > > > > The following suites passed on Linux x86/Windows x86_64
> > > > platforms:
> > > > > > Ant
> > > > > > > > > Scenario (or self-hosting), Axis application, Dacapo, DRLVM
> > > > > > regression
> > > > > > > > > tests, Geronimo Unit Tests, Scimark, Tomcat scenario, VTS
> VM Test
> > > > > > > Suite.
> > > > > > > > >
> > > > > > > > > Most of the failures are known issues (for M6). Although
> we can
> > > > > > > observe
> > > > > > > > > 15~20 new issues, those issues happen only in 1 platform
> and they
> > > > > > look
> > > > > > > > more
> > > > > > > > > like the intermittent/timeout issues (less reproducible) to
> me.
> > > > > > Overall
> > > > > > > I
> > > > > > > > > myself would like to think r681495 is more stable than M6.
> > > > > > > > >
> > > > > > > > > Please add your comments and clarifications (please also
> see M6
> > > > > > > testing
> > > > > > > > > results http://people.apache.org/~smishura/r653525/<
> http://people.apache.org/%7Esmishura/r653525/>
> > > > <
> > > > > > http://people.apache.org/%7Esmishura/r653525/>
> > > > > > > <
> > > > > > > > http://people.apache.org/%7Esmishura/r653525/>
> > > > > > > > > ,
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200805.mbox/%3c6e47b64f0805070304l38845ee0se01fb93fbfc05586@mail.gmail.com%3eand
> > > > > > > > > integrity testing results
> > > > > > > > > http://people.apache.org/~chunrong/harmony-integrity/<
> http://people.apache.org/%7Echunrong/harmony-integrity/>
> > > > <
> > > > > > http://people.apache.org/%7Echunrong/harmony-integrity/>
> > > > > > > <
> > > > > > > > http://people.apache.org/%7Echunrong/harmony-integrity/>as a
> > > > > > > comparison).
> > > > > > > > >
> > > > > > > > > 1) Classlib:
> > > > > > > > > 1.1) Since r644719 (which committed patch for
> HARMONY-5684)
> > > > > > > > >
> > > > > > > > >
> > > > org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> > > > > > > > >
> > > > > > > > > failed in both platforms
> > > > > > > > >
> > > > > > > > > 1.2) Two failures
> > > > > > > > >
> > > > > > > > >
> org.apache.harmony.luni.tests.java.net.MulticastSocketTest
> > > > > > > (Failed
> > > > > > > > > in windows_x86 running of M6)
> > > > > > > > > tests.api.java.security.PermissionCollectionTest
> > > > > > > (Failed
> > > > > > > > > in M6)
> > > > > > > > >
> > > > > > > > > are observed in Linux x86.
> > > > > > > > >
> > > > > > > > > 2) DRLVM tests:
> > > > > > > > > 2.1) One failure
> > > > > > > > >
> > > > > > > > > java.lang.ClassGenericsTest.test_2
> > > > > > > > >
> > > > > > > > > is observed in Linux x86 snapshot testing.
> > > > > > > > > I can see some old discussion in the mailing list
> about
> > > > that
> > > > > > > but
> > > > > > > > I
> > > > > > > > > am not sure the expected status here.
> > > > > > > > > They should be intemittent errors since the
> integrity
> > > > testing
> > > > > > > > just
> > > > > > > > > run well mostly.
> > > > > > > > >
> > > > > > > > > 3) EUTs:
> > > > > > > > >
> > > > > > > > > 3.1) Linux x86: 99.36%
> > > > > > > > > A recorded JIRA for this suite is HARMONY-2914
> which
> > > > wastes
> > > > > > > file
> > > > > > > > > handlers and makes system unstable.
> > > > > > > > >
> > > > > > > > > 4) Functional:
> > > > > > > > > 4.1) Old regressions on both platforms:
> > > > > > > > > api.java.text.MessageFormat (HARMONY-5430)
> > > > > > > > > api.java.util.jar.Manifest (HARMONY-5473)
> > > > > > > > > api.java.beans.beancontext.BeanContextTest (also in
> M6,
> > > > > > > recorded
> > > > > > > > > as regression caused by changes in locale data)
> > > > > > > > > api.java.beans.persistence.EncoderTest (also in
> M6,
> > > > recorded
> > > > > > > as
> > > > > > > > > regression in the beans module)
> > > > > > > > > api.java.beans.persistence.EncoderDecoderTest (also
> in
> > > > M6,
> > > > > > > > > regression in the beans module)
> > > > > > > > > reg.vm.btest5625 (also in M6, recorded as
> intermittent
> > > > and
> > > > > > not
> > > > > > > > > reproducible manually)
> > > > > > > > >
> > > > > > > > > 4.2) Old regressions on 1 platform
> > > > > > > > > api.java.rmi.basicexception (ERROR in Linux x86,
> > > > > > HARMONY-5823)
> > > > > > > > > api.java.rmi.basicregistry.RemoteServerTest (ERROR
> in
> > > > Linux
> > > > > > > x86,
> > > > > > > > > HARMONY-5823)
> > > > > > > > > jpda.jdwp.scenario.ST07.ST07Test (ERROR in windows
> > > > x86_64, in
> > > > > > > M6
> > > > > > > > it
> > > > > > > > > is recorded as regression since M4)
> > > > > > > > > java.math.F_BigIntegerMatrixMultiplyTest_01 (ERROR
> on
> > > > Linux
> > > > > > > x86,
> > > > > > > > > recorded as Timeout, not reproducible
> > > > > > > > > in M6)
> > > > > > > > > reg.vm.btest5717 (ERROR on Windows X86_64, recorded
> as
> > > > > > > "timeout,
> > > > > > > > > the test is too heavy" in M6)
> > > > > > > > >
> jit.HLO.inline.ControlFlow.IfElse.IfElse1.IfElseTest1
> > > > (FAILED
> > > > > > > in
> > > > > > > > > windows x86_64, recorded as "looks like
> > > > > > > > > issue in test" in M6)
> > > > > > > > > jit.HLO.devirt.Runtime.RuntimeExtend1 (FAILED on
> windows
> > > > > > > x86_64,
> > > > > > > > in
> > > > > > > > > M6 it is recorded as not regression and started to fail on
> M5)
> > > > > > > > > reg.vm.btest6353.Btest6353 (ERROR on Windows
> x86_64,
> > > > recorded
> > > > > > > > also
> > > > > > > > > failed on M3 and might be issue with the test)
> > > > > > > > >
> > > > > > > > > 4.3) New regressions on 1 platform (looks intermittent)
> > > > > > > > > reg.jit.btest8029.Btest8029 (FAILED in Linux x86)
> > > > > > > > > func.reg.jit.btest5710.Btest5710 (FAILED in Linux
> x86)
> > > > > > > > >
> > > > api.java.security.cert.F_CertPathTest_06.F_CertPathTest_06
> > > > > > > (ERROR
> > > > > > > > > in Linux x86)
> > > > > > > > >
> > > > api.java.security.cert.F_CertPathTest_05.F_CertPathTest_05
> > > > > > > (ERROR
> > > > > > > > > in Linux x86)
> > > > > > > > >
> > > > > > > > > 5) JDKTools Tests:
> > > > > > > > > Several timeouts are observed in Linux x86 snapshot
> running.
> > > > They
> > > > > > > are:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch002
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch003
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch004
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.Events.CombinedEventsTest.testCombinedEvents_04
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest.testAttachConnector001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest.testMethodEvent001
> > > > > > > > >
> > > > > > > > >
> > > > org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest.testResume
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest.testThreadEnd001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest.testThreadStart001
> > > > > > > > > The Linux-only timeouts are also observed in the
> integrity
> > > > testing
> > > > > > > > > results.
> > > > > > > > > JIRA HARMONY-5833 has been filed for one of them.
> > > > > > > > >
> > > > > > > > > 6) JettyScenario:
> > > > > > > > > The Linux x86 running failed because of the unresolved
> > > > > > HARMONY-5219.
> > > > > > > > >
> > > > > > > > > 7) Reliability:
> > > > > > > > > Several failures are observed in windows x86_64 running.
> > > > > > > > > 7.1) Old regressions
> > > > > > > > > api.net.DatagramTest (HARMONY-5531)
> > > > > > > > > api.text.DecimalFormat_Locales - (in M6 it is
> recorded as
> > > > > > also
> > > > > > > > > intermittent in M5)
> > > > > > > > >
> > > > > > > > > 7.2) New/intemittent regressions
> > > > > > > > > api.kernel.thread.ThreadLocalTest.ThreadLocalTest
> > > > > > > > > api.kernel.exec.RunExec
> > > > > > > > >
> > > > > > > > > 8) Stress
> > > > > > > > > Different test cases failed on different platforms.
> > > > > > > > > 8.1) Timeouts on Linux x86.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD003.ThreadTest003
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD007.ThreadTest007
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD009.ThreadTest009
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD011.ThreadTest011
> > > > > > > > >
> > > > > > > > > 8.2) Failed cases on Windows x86_64 with unknown
> reasons.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.classloader.MixThreads.TreeClasses.testTreeClasses2
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> stress.org.apache.harmony.test.stress.classloader.NotSynchThreads.TreeClasses.testTreeClasses
> > > > > > > > >
> > > > > > > > > I have not found records for them.
> > > > > > > > >
> > > > > > > > > 9) Strut_test
> > > > > > > > > Broken with same error report as M6.
> > > > > > > > >
> > > > > > > > > 10) Eclipse Hello World Application.
> > > > > > > > > Although the testing framework just reports EUT-API
> status as
> > > > > > > > "PASSED".
> > > > > > > > > A fresh workspace running just failed in configuration
> stage (
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200805.mbox/%3c6e47b64f0805120106o387a49f1rfb2c33d1042d2f41@mail.gmail.com%3e
> > > > > > > > > )
> > > > > > > > > since SVN commit 641928 (which committed patch for
> HARMONY-4569).
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > > chunrong
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Unless stated otherwise above:
> > > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > > 741598.
> > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
> > > >
> > >
> >
> >
> > --
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
>
>
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Re: [testing] first M7 candidate (r681495) testing status
Posted by Sian January <si...@googlemail.com>.
Thanks Ligang - I meant to get to this at some point before M8 but
you've saved me a job now :-)
On 08/09/2008, Ligang Wang <wa...@gmail.com> wrote:
> Sian, I looked at the Throwable.initCause() problem and agree with you.
>
> My observation on this issue is as follows.
>
> DRLVM implementation of Throwable.initCause():
> public Throwable initCause(Throwable initialCause) {
> if (initialCause == this) {
> throw new IllegalArgumentException("A throwable cannot
> be its own cause.");
> }
> // second call of initCause(Throwable)
> if (cause != this) {
> throw new IllegalStateException("A cause can be set at
> most once." +
> " Illegal attempt to re-set the cause of " + this);
> }
> cause = initialCause;
> return this;
> }
> Firstly "this" is assigned to the private member "cause".
>
> CLASSLIB implementation of Throwable.initCause():
> public synchronized Throwable initCause(Throwable throwable) {
> if (cause == this) {
> if (throwable != this) {
> cause = throwable;
> return this;
> }
> throw new IllegalArgumentException("Cause cannot be the
> receiver");
> }
> throw new IllegalStateException("Cause already initialized");
> }
> Firstly "this" is assigned to the private member "cause".
>
> The description of of JavaDoc of Throwable.initCause():
> public Throwable<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html>
> *initCause*(Throwable<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html>
> cause)
> Initializes the *cause* of this throwable to the specified value. This
> method can be called at most once.
> *Throws:*
> IllegalArgumentException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalArgumentException.html>-
> if
> cause is this throwable. (A throwable cannot be its own cause.)
> IllegalStateException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalStateException.html>-
> if this throwable was created with
> Throwable(Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#Throwable(java.lang.Throwable)>or
> Throwable(String,Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#Throwable(java.lang.String,
> java.lang.Throwable)>, or this method has already been called on this
> throwable.
>
> The first exception is thrown when "cause" parameter is "this", and the
> second exception is thrown when "causce", the instance member, is set for
> the second time. From the description of JavaDoc, we can see there is an
> overlap between the two exceptions. If initCause is called for the second
> time and "cause" parameter is "this", which exception will be thrown?
> JavaDoc doesn't have clear description on this. The DRLVM implementation
> throws the first exception, while the CLASSLIB implementation throws the
> second. We can not tell which is better.
>
> But as Sian said, JavaDoc for ServerCloneException says that "Invoking the
> method Throwable.initCause(Throwable)<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/Throwable.html#initCause(java.lang.Throwable)>on
> an instance of
> ServerCloneException always throws
> IllegalStateException<file:///C:/Program%20Files/Java/jdk-1.5.0-docs/api/java/lang/IllegalStateException.html>".
> With this statement, we may see the CLASSLIB implementation is better. I
> have modified ServerCloneExceptionTest.test_Constructor_String() and
> Throwable.initCause() accordingly. The related JIRA issue is
> https://issues.apache.org/jira/browse/HARMONY-5971.
>
> Thanks,
> Ligang
>
>
> On Wed, Aug 13, 2008 at 6:50 PM, Sian January <si...@googlemail.com>wrote:
>
> > Oliver has helped me track this down this morning, and it's occuring
> > because there are differences between the versions of
> > Throwable.initCause(..) in luni and in DRLVM. According to the spec,
> > I think the test should be changed to check for IllegalStateException
> > instead of IllegalArgumentException and then I think the version of
> > Throwable in DRLVM should be changed to behave the same as the one in
> > luni. However I don't think this is a big deal for M7 because I don't
> > think it's very serious and it's not a regression since M6. What does
> > anyone else think?
> >
> > Sian
> >
> > On 13/08/2008, Sian January <si...@googlemail.com> wrote:
> > > I think the code is right and the test is wrong here, because the
> > > Javadoc for ServerCloneException says that "Invoking the method
> > > Throwable.initCause(Throwable) on an instance of ServerCloneException
> > > always throws IllegalStateException."
> > >
> > > What is really confusing me is how this can be passing for anyone
> > > else... The exclude list hasn't changed recently and I don't see how
> > > it could be VM dependent either.
> > >
> > >
> > > On 13/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > > On Tue, Aug 12, 2008 at 10:18 AM, Sian January
> > > > <si...@googlemail.com>wrote:
> > > >
> > > > > I am not seeing the management failures on my local (Windows)
> > machine,
> > > > > but I'm seeing an rmi failure:
> > > > >
> > > > >
> > > > >
> > org.apache.harmony.rmi.server.ServerCloneExceptionTest.test_Constructor_String
> > > > > Cause already initialized
> > > > > java.lang.IllegalStateException: Cause already initialized
> > > > > at java.lang.Throwable.initCause(Throwable.java:293)
> > > > > at
> > > > >
> > org.apache.harmony.rmi.server.ServerCloneExceptionTest.test_Constructor_String(ServerCloneExceptionTest.java:70)
> > > > > at
> > java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > >
> > > >
> > > > This test [1] is creating an exception and then passing itself into
> > > > 'initCause', which should throw IllegalArgumentException. Looking at
> > the
> > > > code though, it does look like there's a bug, as 'null' is being passed
> > to
> > > > the super() constructor, which will mess up Throwable, since it
> > initializes
> > > > 'cause' to 'this', so Throwable will think the cause is already set.
> > > >
> > > > Did this test recently get removed from an exclusion list?
> > > >
> > > >
> > > > [1]
> > > >
> > http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/rmi/src/test/api/java/org/apache/harmony/rmi/server/ServerCloneExceptionTest.java?view=annotate
> > > >
> > > > >
> > > > >
> > > > > and an intermittent failure in java.net:
> > > > >
> > > > >
> > > > >
> > org.apache.harmony.luni.tests.java.net.URLConnectionTest.test_getInputStream
> > > > >
> > > > > Error receiving content coded data:
> > > > > junit.framework.AssertionFailedError: Error receiving content coded
> > data:
> > > > > at
> > tests.support.Support_HttpTests.runTests(Support_HttpTests.java:15)
> > > > > at
> > > > >
> > org.apache.harmony.luni.tests.java.net.URLConnectionTest.test_getInputStream(URLConnectionTest.java:632)
> > > > > at
> > java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > > >
> > > > > Is anyone else seeing these?
> > > > >
> > > > > Sian
> > > > >
> > > > > On 12/08/2008, chunrong lai <ch...@gmail.com> wrote:
> > > > > > Thanks.
> > > > > > I think the standard scripts produce that site although I always
> > added
> > > > > > publish/e-mail notification setup before install/run the test
> > suites.
> > > > > > It is understandable that some tests in classlib-test and
> > drlvm-test
> > > > > get
> > > > > > failing report. We just need to understand the failures.
> > > > > > As reported in M6,
> > > > > > org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest,
> > > > > >
> > > > >
> > org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> > > > > > etc fail classlib-test.
> > > > > > Also we observed that java.lang.ClassGenericsTest.test_2
> > sometimes fail
> > > > > > drlvm-test.
> > > > > > Another timeout issue of drlvm-test comes from
> > > > > > thread.SmallStackThreadTest_jit, as discussed in HARMONY-4601, the
> > test
> > > > > case
> > > > > > may run very slow when system resource is tight and finally
> > introduce a
> > > > > > timeout. Re-running the suite generally fixes the timeout.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 8/12/08, Nathan Beyer <nd...@apache.org> wrote:
> > > > > > >
> > > > > > > It's the tests that are failing - both classlib-test and
> > drlvm-test.
> > > > > > >
> > > > > > > What's the specific integrity setup that's being used for that
> > site?
> > > > > Does
> > > > > > > the standard out-of-the-box buildtest scripts produce that site?
> > > > > > >
> > > > > > > -Nathan
> > > > > > >
> > > > > > > On Mon, Aug 11, 2008 at 9:05 PM, chunrong lai <
> > chunronglai@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > hi, Nathan:
> > > > > > > > Steps to run testing cycle are listed in
> > > > > > > > http://harmony.apache.org/subcomponents/buildtest/index.html.
> > One
> > > > > > > > integrity
> > > > > > > > testing example is
> > > > > > > >
> > > > >
> > http://harmony.apache.org/subcomponents/buildtest/howto.html#Extended.
> > > > > > > > What is the error message you met (in what step)? What is
> > the
> > > > > > > content
> > > > > > > > of the framework.local.properties file? I think that will help
> > to
> > > > > figure
> > > > > > > > out
> > > > > > > > the problem.
> > > > > > > >
> > > > > > > >
> > > > > > > > On 8/12/08, Nathan Beyer <nd...@apache.org> wrote:
> > > > > > > > >
> > > > > > > > > What's being used to produce the integrity tests? I have an
> > x86_64
> > > > > > > Linux
> > > > > > > > > box
> > > > > > > > > that I can dedicate to testing. I've tried just using
> > buildtest
> > > > > with
> > > > > > > > > 'classlib,drlvm,classib-test,drlvm-test', but I haven't
> > gotten a
> > > > > clean
> > > > > > > > pass
> > > > > > > > > yet.
> > > > > > > > >
> > > > > > > > > -Nathan
> > > > > > > > >
> > > > > > > > > On Mon, Aug 11, 2008 at 12:26 PM, chunrong lai <
> > > > > chunronglai@gmail.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Hi, all:
> > > > > > > > > >
> > > > > > > > > > Here is r681495 snapshot testing status:
> > > > > > > > > >
> > http://people.apache.org/~chunrong/snapshots/r681495/index.html<
> > http://people.apache.org/%7Echunrong/snapshots/r681495/index.html>
> > > > > <
> > > > > > >
> > http://people.apache.org/%7Echunrong/snapshots/r681495/index.html>
> > > > > > > > <
> > > > > > > > >
> > http://people.apache.org/%7Echunrong/snapshots/r681495/index.html
> > > > > >.
> > > > > > > > > > I am using
> > > > > > > > > > two platforms (Linux x86, windows x86_64) at the moment.
> > > > > Hopefully we
> > > > > > > > > will
> > > > > > > > > > have other two platforms in future for M8. Well, although
> > we are
> > > > > > > > testing
> > > > > > > > > > only two platforms for M7, my experience is that the status
> > for
> > > > > > > another
> > > > > > > > > two
> > > > > > > > > > platforms should be not worse or just include some extra
> > > > > intermittent
> > > > > > > > > > errors
> > > > > > > > > > which can be investigated in some later stages.
> > > > > > > > > >
> > > > > > > > > > The following suites passed on Linux x86/Windows x86_64
> > > > > platforms:
> > > > > > > Ant
> > > > > > > > > > Scenario (or self-hosting), Axis application, Dacapo, DRLVM
> > > > > > > regression
> > > > > > > > > > tests, Geronimo Unit Tests, Scimark, Tomcat scenario, VTS
> > VM Test
> > > > > > > > Suite.
> > > > > > > > > >
> > > > > > > > > > Most of the failures are known issues (for M6). Although
> > we can
> > > > > > > > observe
> > > > > > > > > > 15~20 new issues, those issues happen only in 1 platform
> > and they
> > > > > > > look
> > > > > > > > > more
> > > > > > > > > > like the intermittent/timeout issues (less reproducible) to
> > me.
> > > > > > > Overall
> > > > > > > > I
> > > > > > > > > > myself would like to think r681495 is more stable than M6.
> > > > > > > > > >
> > > > > > > > > > Please add your comments and clarifications (please also
> > see M6
> > > > > > > > testing
> > > > > > > > > > results http://people.apache.org/~smishura/r653525/<
> > http://people.apache.org/%7Esmishura/r653525/>
> > > > > <
> > > > > > > http://people.apache.org/%7Esmishura/r653525/>
> > > > > > > > <
> > > > > > > > > http://people.apache.org/%7Esmishura/r653525/>
> > > > > > > > > > ,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200805.mbox/%3c6e47b64f0805070304l38845ee0se01fb93fbfc05586@mail.gmail.com%3eand
> > > > > > > > > > integrity testing results
> > > > > > > > > > http://people.apache.org/~chunrong/harmony-integrity/<
> > http://people.apache.org/%7Echunrong/harmony-integrity/>
> > > > > <
> > > > > > > http://people.apache.org/%7Echunrong/harmony-integrity/>
> > > > > > > > <
> > > > > > > > > http://people.apache.org/%7Echunrong/harmony-integrity/>as a
> > > > > > > > comparison).
> > > > > > > > > >
> > > > > > > > > > 1) Classlib:
> > > > > > > > > > 1.1) Since r644719 (which committed patch for
> > HARMONY-5684)
> > > > > > > > > >
> > > > > > > > > >
> > > > > org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> > > > > > > > > >
> > > > > > > > > > failed in both platforms
> > > > > > > > > >
> > > > > > > > > > 1.2) Two failures
> > > > > > > > > >
> > > > > > > > > >
> > org.apache.harmony.luni.tests.java.net.MulticastSocketTest
> > > > > > > > (Failed
> > > > > > > > > > in windows_x86 running of M6)
> > > > > > > > > > tests.api.java.security.PermissionCollectionTest
> > > > > > > > (Failed
> > > > > > > > > > in M6)
> > > > > > > > > >
> > > > > > > > > > are observed in Linux x86.
> > > > > > > > > >
> > > > > > > > > > 2) DRLVM tests:
> > > > > > > > > > 2.1) One failure
> > > > > > > > > >
> > > > > > > > > > java.lang.ClassGenericsTest.test_2
> > > > > > > > > >
> > > > > > > > > > is observed in Linux x86 snapshot testing.
> > > > > > > > > > I can see some old discussion in the mailing list
> > about
> > > > > that
> > > > > > > > but
> > > > > > > > > I
> > > > > > > > > > am not sure the expected status here.
> > > > > > > > > > They should be intemittent errors since the
> > integrity
> > > > > testing
> > > > > > > > > just
> > > > > > > > > > run well mostly.
> > > > > > > > > >
> > > > > > > > > > 3) EUTs:
> > > > > > > > > >
> > > > > > > > > > 3.1) Linux x86: 99.36%
> > > > > > > > > > A recorded JIRA for this suite is HARMONY-2914
> > which
> > > > > wastes
> > > > > > > > file
> > > > > > > > > > handlers and makes system unstable.
> > > > > > > > > >
> > > > > > > > > > 4) Functional:
> > > > > > > > > > 4.1) Old regressions on both platforms:
> > > > > > > > > > api.java.text.MessageFormat (HARMONY-5430)
> > > > > > > > > > api.java.util.jar.Manifest (HARMONY-5473)
> > > > > > > > > > api.java.beans.beancontext.BeanContextTest (also in
> > M6,
> > > > > > > > recorded
> > > > > > > > > > as regression caused by changes in locale data)
> > > > > > > > > > api.java.beans.persistence.EncoderTest (also in
> > M6,
> > > > > recorded
> > > > > > > > as
> > > > > > > > > > regression in the beans module)
> > > > > > > > > > api.java.beans.persistence.EncoderDecoderTest (also
> > in
> > > > > M6,
> > > > > > > > > > regression in the beans module)
> > > > > > > > > > reg.vm.btest5625 (also in M6, recorded as
> > intermittent
> > > > > and
> > > > > > > not
> > > > > > > > > > reproducible manually)
> > > > > > > > > >
> > > > > > > > > > 4.2) Old regressions on 1 platform
> > > > > > > > > > api.java.rmi.basicexception (ERROR in Linux x86,
> > > > > > > HARMONY-5823)
> > > > > > > > > > api.java.rmi.basicregistry.RemoteServerTest (ERROR
> > in
> > > > > Linux
> > > > > > > > x86,
> > > > > > > > > > HARMONY-5823)
> > > > > > > > > > jpda.jdwp.scenario.ST07.ST07Test (ERROR in windows
> > > > > x86_64, in
> > > > > > > > M6
> > > > > > > > > it
> > > > > > > > > > is recorded as regression since M4)
> > > > > > > > > > java.math.F_BigIntegerMatrixMultiplyTest_01 (ERROR
> > on
> > > > > Linux
> > > > > > > > x86,
> > > > > > > > > > recorded as Timeout, not reproducible
> > > > > > > > > > in M6)
> > > > > > > > > > reg.vm.btest5717 (ERROR on Windows X86_64, recorded
> > as
> > > > > > > > "timeout,
> > > > > > > > > > the test is too heavy" in M6)
> > > > > > > > > >
> > jit.HLO.inline.ControlFlow.IfElse.IfElse1.IfElseTest1
> > > > > (FAILED
> > > > > > > > in
> > > > > > > > > > windows x86_64, recorded as "looks like
> > > > > > > > > > issue in test" in M6)
> > > > > > > > > > jit.HLO.devirt.Runtime.RuntimeExtend1 (FAILED on
> > windows
> > > > > > > > x86_64,
> > > > > > > > > in
> > > > > > > > > > M6 it is recorded as not regression and started to fail on
> > M5)
> > > > > > > > > > reg.vm.btest6353.Btest6353 (ERROR on Windows
> > x86_64,
> > > > > recorded
> > > > > > > > > also
> > > > > > > > > > failed on M3 and might be issue with the test)
> > > > > > > > > >
> > > > > > > > > > 4.3) New regressions on 1 platform (looks intermittent)
> > > > > > > > > > reg.jit.btest8029.Btest8029 (FAILED in Linux x86)
> > > > > > > > > > func.reg.jit.btest5710.Btest5710 (FAILED in Linux
> > x86)
> > > > > > > > > >
> > > > > api.java.security.cert.F_CertPathTest_06.F_CertPathTest_06
> > > > > > > > (ERROR
> > > > > > > > > > in Linux x86)
> > > > > > > > > >
> > > > > api.java.security.cert.F_CertPathTest_05.F_CertPathTest_05
> > > > > > > > (ERROR
> > > > > > > > > > in Linux x86)
> > > > > > > > > >
> > > > > > > > > > 5) JDKTools Tests:
> > > > > > > > > > Several timeouts are observed in Linux x86 snapshot
> > running.
> > > > > They
> > > > > > > > are:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch001
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch002
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch003
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest.testDebuggerLaunch004
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.Events.CombinedEventsTest.testCombinedEvents_04
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest.testAttachConnector001
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest.testMethodEvent001
> > > > > > > > > >
> > > > > > > > > >
> > > > > org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest.testResume
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest.testThreadEnd001
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest.testThreadStart001
> > > > > > > > > > The Linux-only timeouts are also observed in the
> > integrity
> > > > > testing
> > > > > > > > > > results.
> > > > > > > > > > JIRA HARMONY-5833 has been filed for one of them.
> > > > > > > > > >
> > > > > > > > > > 6) JettyScenario:
> > > > > > > > > > The Linux x86 running failed because of the unresolved
> > > > > > > HARMONY-5219.
> > > > > > > > > >
> > > > > > > > > > 7) Reliability:
> > > > > > > > > > Several failures are observed in windows x86_64 running.
> > > > > > > > > > 7.1) Old regressions
> > > > > > > > > > api.net.DatagramTest (HARMONY-5531)
> > > > > > > > > > api.text.DecimalFormat_Locales - (in M6 it is
> > recorded as
> > > > > > > also
> > > > > > > > > > intermittent in M5)
> > > > > > > > > >
> > > > > > > > > > 7.2) New/intemittent regressions
> > > > > > > > > > api.kernel.thread.ThreadLocalTest.ThreadLocalTest
> > > > > > > > > > api.kernel.exec.RunExec
> > > > > > > > > >
> > > > > > > > > > 8) Stress
> > > > > > > > > > Different test cases failed on different platforms.
> > > > > > > > > > 8.1) Timeouts on Linux x86.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD003.ThreadTest003
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD007.ThreadTest007
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD009.ThreadTest009
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.jpda.jdwp.scenario.THREAD011.ThreadTest011
> > > > > > > > > >
> > > > > > > > > > 8.2) Failed cases on Windows x86_64 with unknown
> > reasons.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.classloader.MixThreads.TreeClasses.testTreeClasses2
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > stress.org.apache.harmony.test.stress.classloader.NotSynchThreads.TreeClasses.testTreeClasses
> > > > > > > > > >
> > > > > > > > > > I have not found records for them.
> > > > > > > > > >
> > > > > > > > > > 9) Strut_test
> > > > > > > > > > Broken with same error report as M6.
> > > > > > > > > >
> > > > > > > > > > 10) Eclipse Hello World Application.
> > > > > > > > > > Although the testing framework just reports EUT-API
> > status as
> > > > > > > > > "PASSED".
> > > > > > > > > > A fresh workspace running just failed in configuration
> > stage (
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200805.mbox/%3c6e47b64f0805120106o387a49f1rfb2c33d1042d2f41@mail.gmail.com%3e
> > > > > > > > > > )
> > > > > > > > > > since SVN commit 641928 (which committed patch for
> > HARMONY-4569).
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > chunrong
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Unless stated otherwise above:
> > > > > IBM United Kingdom Limited - Registered in England and Wales with
> > number
> > > > > 741598.
> > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > > > >
> > > >
> > >
> > >
> > > --
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU
> > >
> >
> >
> > --
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> >
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU