You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Sian January <si...@googlemail.com> on 2008/08/15 15:26:49 UTC
[vote] Declare r681495 as M7
Hi everyone,
We have completed a testing cycle for r681495 and evaluated the results [1].
There are some test failures, but most of them are either intermittent
or were also failing in M6. However if anyone thinks any of these
test failures are blockers and has not yet had a chance to say, please
speak up now.
Otherwise, shall we declare r681495 as M7?
Thanks,
Sian
[1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
--
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: [vote] Declare r681495 as M7
Posted by Sean Qiu <se...@gmail.com>.
+1
2008/8/16 Tony Wu <wu...@gmail.com>:
> +1
>
> On 8/16/08, Xiao-Feng Li <xi...@gmail.com> wrote:
>> +1
>>
>> On Fri, Aug 15, 2008 at 9:26 PM, Sian January
>> <si...@googlemail.com> wrote:
>> > Hi everyone,
>> >
>> > We have completed a testing cycle for r681495 and evaluated the results [1].
>> >
>> > There are some test failures, but most of them are either intermittent
>> > or were also failing in M6. However if anyone thinks any of these
>> > test failures are blockers and has not yet had a chance to say, please
>> > speak up now.
>> >
>> > Otherwise, shall we declare r681495 as M7?
>> >
>> > Thanks,
>> >
>> > Sian
>> >
>> >
>> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>> >
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>> --
>> http://xiao-feng.blogspot.com
>>
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>
--
Best Regards
Sean, Xiao Xia Qiu
China Software Development Lab, IBM
Re: [vote] Declare r681495 as M7
Posted by Tony Wu <wu...@gmail.com>.
+1
On 8/16/08, Xiao-Feng Li <xi...@gmail.com> wrote:
> +1
>
> On Fri, Aug 15, 2008 at 9:26 PM, Sian January
> <si...@googlemail.com> wrote:
> > Hi everyone,
> >
> > We have completed a testing cycle for r681495 and evaluated the results [1].
> >
> > There are some test failures, but most of them are either intermittent
> > or were also failing in M6. However if anyone thinks any of these
> > test failures are blockers and has not yet had a chance to say, please
> > speak up now.
> >
> > Otherwise, shall we declare r681495 as M7?
> >
> > Thanks,
> >
> > Sian
> >
> >
> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> >
> >
> > --
> > 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
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Tony Wu
China Software Development Lab, IBM
Re: [vote] Declare r681495 as M7
Posted by Xiao-Feng Li <xi...@gmail.com>.
+1
On Fri, Aug 15, 2008 at 9:26 PM, Sian January
<si...@googlemail.com> wrote:
> Hi everyone,
>
> We have completed a testing cycle for r681495 and evaluated the results [1].
>
> There are some test failures, but most of them are either intermittent
> or were also failing in M6. However if anyone thinks any of these
> test failures are blockers and has not yet had a chance to say, please
> speak up now.
>
> Otherwise, shall we declare r681495 as M7?
>
> Thanks,
>
> Sian
>
>
> [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>
>
> --
> 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
>
--
http://xiao-feng.blogspot.com
Re: [vote] Declare r681495 as M7
Posted by Tim Ellison <t....@gmail.com>.
I'm just starting to catch up on e-mails after a long holiday <g> so
won't vote on this release as I've not had a chance to check it
thoroughly (and don't want to hold things up doing so now).
I can help to push the release out to mirrors / website etc. once people
are happy with it.
Regards,
Tim
Sian January wrote:
> Hi everyone,
>
> We have completed a testing cycle for r681495 and evaluated the results [1].
>
> There are some test failures, but most of them are either intermittent
> or were also failing in M6. However if anyone thinks any of these
> test failures are blockers and has not yet had a chance to say, please
> speak up now.
>
> Otherwise, shall we declare r681495 as M7?
>
> Thanks,
>
> Sian
>
>
> [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>
>
Re: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nd...@apache.org>.
I suspect that the PermissionCollectionTest failure began with this
commit - http://svn.apache.org/viewvc?view=rev&revision=612718. As of
this commit, SimpleTimeZone began delegating to ICU's TimeZone
classes, which end up loading the class ICUDebug [1], which performs a
System.getProperty("java.version") inline without catching a
SecurityException.
It looks like we need to add a privileged block around this bit of code.
[1] http://source.icu-project.org/repos/icu/icu4j/tags/release-3-8-1/src/com/ibm/icu/impl/ICUDebug.java
On Mon, Aug 18, 2008 at 9:04 PM, chunrong lai <ch...@gmail.com> wrote:
> I have not checked when the PermissionCollectionTest issue started but I can
> see the failure in M6 so I think it is not a new bug.
> http://people.apache.org/~smishura/r653525/Linux_x86_64/classlib-test/tests/api/java/security/1390_PermissionCollectionTest.html<http://people.apache.org/~smishura/r653525/Linux_x86_64/classlib-test/>
>
> The page http://people.apache.org/~chunrong/harmony-integrity/ includes the
> integrity testing results of the four platforms, with less test suites than
> the snapshot testing cycle. I see that the results of win32 is not worse
> than the other three platforms there.
>
>
> On 8/19/08, Nathan Beyer <nd...@apache.org> wrote:
>>
>> Is there a bug logged for the PermissionCollectionTest issue?
>>
>> Additionally, I thought you mentioned that you had a linux x86_64 box
>> running. The integration test page that's referenced for this vote
>> shows Windows 64 and Linux 32. What about Windows 32?
>>
>> -Nathan
>>
>> On Sun, Aug 17, 2008 at 11:51 PM, chunrong lai <ch...@gmail.com>
>> wrote:
>> > Thanks for the sharing. It is strange that I did not observe the
>> unpack200
>> > failures.
>> > Other classlib failures are not new. The guity commit of the management
>> > failures has been identified as r644719.
>> > The issues in jdktools-test are "timeouts" in our testing. They are not
>> new
>> > either. Moreover the standalone running, for example "java -cp
>> >
>> "/home/laichunrong/apache-ant-1.6.5/lib/junit.jar:./infra/build/checkouts/jdktools/build/tests/classes/"
>> > org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest" just report
>> "OK"
>> > here (should set LD_LIBRARY_PATH to include
>> >
>> ./infra/build/checkouts/jdktools/modules/jpda/src/main/native/jdwp/unix/transport).
>> > So
>> > I do not think that they are blockers for now.
>> > Thanks.
>> >
>> > On 8/18/08, Nathan Beyer <nd...@apache.org> wrote:
>> >>
>> >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>> >>
>> >> Here are the failures I'm seeing, consistently, in classlib-test. The
>> >> unpack200 test failures concern me.
>> >>
>> >> error testGetAttribute
>> >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
>> >> error testGetCollectionUsage
>> >>
>> >>
>> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
>> >> failure testWithSql
>> >> org.apache.harmony.unpack200.tests.ArchiveTest
>> >> failure
>> >> testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
>> >> failure test_impliesLjava_security_Permission
>> >> tests.api.java.security.PermissionCollectionTest
>> >>
>> >> Here are the failures I'm seeing, consistently, in jdktools-test.
>> >>
>> >> error testDebuggerLaunch001
>> >>
>> >>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> >> error testDebuggerLaunch002
>> >>
>> >>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> >> error testDebuggerLaunch003
>> >>
>> >>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> >> error testDebuggerLaunch004
>> >>
>> >>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> >> error testAttachConnector001
>>
>> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
>> >> error testClearBreakpoint001
>> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
>> >> error testMethodEvent001
>>
>> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
>> >> error
>> >>
>> testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
>> >> error testThreadEnd001
>> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
>> >> error testThreadStart001
>> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>> >>
>> >> drlvm-test and drlvm-reg-test are passing.
>> >>
>> >> -Nathan
>> >>
>> >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
>> >> <si...@googlemail.com> wrote:
>> >> > Hi everyone,
>> >> >
>> >> > We have completed a testing cycle for r681495 and evaluated the
>> results
>> >> [1].
>> >> >
>> >> > There are some test failures, but most of them are either intermittent
>> >> > or were also failing in M6. However if anyone thinks any of these
>> >> > test failures are blockers and has not yet had a chance to say, please
>> >> > speak up now.
>> >> >
>> >> > Otherwise, shall we declare r681495 as M7?
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Sian
>> >> >
>> >> >
>> >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>> >> >
>> >> >
>> >> > --
>> >> > 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: [vote] Declare r681495 as M7
Posted by chunrong lai <ch...@gmail.com>.
I have not checked when the PermissionCollectionTest issue started but I can
see the failure in M6 so I think it is not a new bug.
http://people.apache.org/~smishura/r653525/Linux_x86_64/classlib-test/tests/api/java/security/1390_PermissionCollectionTest.html<http://people.apache.org/~smishura/r653525/Linux_x86_64/classlib-test/>
The page http://people.apache.org/~chunrong/harmony-integrity/ includes the
integrity testing results of the four platforms, with less test suites than
the snapshot testing cycle. I see that the results of win32 is not worse
than the other three platforms there.
On 8/19/08, Nathan Beyer <nd...@apache.org> wrote:
>
> Is there a bug logged for the PermissionCollectionTest issue?
>
> Additionally, I thought you mentioned that you had a linux x86_64 box
> running. The integration test page that's referenced for this vote
> shows Windows 64 and Linux 32. What about Windows 32?
>
> -Nathan
>
> On Sun, Aug 17, 2008 at 11:51 PM, chunrong lai <ch...@gmail.com>
> wrote:
> > Thanks for the sharing. It is strange that I did not observe the
> unpack200
> > failures.
> > Other classlib failures are not new. The guity commit of the management
> > failures has been identified as r644719.
> > The issues in jdktools-test are "timeouts" in our testing. They are not
> new
> > either. Moreover the standalone running, for example "java -cp
> >
> "/home/laichunrong/apache-ant-1.6.5/lib/junit.jar:./infra/build/checkouts/jdktools/build/tests/classes/"
> > org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest" just report
> "OK"
> > here (should set LD_LIBRARY_PATH to include
> >
> ./infra/build/checkouts/jdktools/modules/jpda/src/main/native/jdwp/unix/transport).
> > So
> > I do not think that they are blockers for now.
> > Thanks.
> >
> > On 8/18/08, Nathan Beyer <nd...@apache.org> wrote:
> >>
> >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
> >>
> >> Here are the failures I'm seeing, consistently, in classlib-test. The
> >> unpack200 test failures concern me.
> >>
> >> error testGetAttribute
> >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> >> error testGetCollectionUsage
> >>
> >>
> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> >> failure testWithSql
> >> org.apache.harmony.unpack200.tests.ArchiveTest
> >> failure
> >> testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
> >> failure test_impliesLjava_security_Permission
> >> tests.api.java.security.PermissionCollectionTest
> >>
> >> Here are the failures I'm seeing, consistently, in jdktools-test.
> >>
> >> error testDebuggerLaunch001
> >>
> >>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch002
> >>
> >>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch003
> >>
> >>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch004
> >>
> >>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testAttachConnector001
>
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
> >> error testClearBreakpoint001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> >> error testMethodEvent001
>
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
> >> error
> >>
> testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
> >> error testThreadEnd001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> >> error testThreadStart001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
> >>
> >> drlvm-test and drlvm-reg-test are passing.
> >>
> >> -Nathan
> >>
> >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> >> <si...@googlemail.com> wrote:
> >> > Hi everyone,
> >> >
> >> > We have completed a testing cycle for r681495 and evaluated the
> results
> >> [1].
> >> >
> >> > There are some test failures, but most of them are either intermittent
> >> > or were also failing in M6. However if anyone thinks any of these
> >> > test failures are blockers and has not yet had a chance to say, please
> >> > speak up now.
> >> >
> >> > Otherwise, shall we declare r681495 as M7?
> >> >
> >> > Thanks,
> >> >
> >> > Sian
> >> >
> >> >
> >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> >> >
> >> >
> >> > --
> >> > 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: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nd...@apache.org>.
Is there a bug logged for the PermissionCollectionTest issue?
Additionally, I thought you mentioned that you had a linux x86_64 box
running. The integration test page that's referenced for this vote
shows Windows 64 and Linux 32. What about Windows 32?
-Nathan
On Sun, Aug 17, 2008 at 11:51 PM, chunrong lai <ch...@gmail.com> wrote:
> Thanks for the sharing. It is strange that I did not observe the unpack200
> failures.
> Other classlib failures are not new. The guity commit of the management
> failures has been identified as r644719.
> The issues in jdktools-test are "timeouts" in our testing. They are not new
> either. Moreover the standalone running, for example "java -cp
> "/home/laichunrong/apache-ant-1.6.5/lib/junit.jar:./infra/build/checkouts/jdktools/build/tests/classes/"
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest" just report "OK"
> here (should set LD_LIBRARY_PATH to include
> ./infra/build/checkouts/jdktools/modules/jpda/src/main/native/jdwp/unix/transport).
> So
> I do not think that they are blockers for now.
> Thanks.
>
> On 8/18/08, Nathan Beyer <nd...@apache.org> wrote:
>>
>> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>>
>> Here are the failures I'm seeing, consistently, in classlib-test. The
>> unpack200 test failures concern me.
>>
>> error testGetAttribute
>> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
>> error testGetCollectionUsage
>>
>> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
>> failure testWithSql
>> org.apache.harmony.unpack200.tests.ArchiveTest
>> failure
>> testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
>> failure test_impliesLjava_security_Permission
>> tests.api.java.security.PermissionCollectionTest
>>
>> Here are the failures I'm seeing, consistently, in jdktools-test.
>>
>> error testDebuggerLaunch001
>>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch002
>>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch003
>>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch004
>>
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testAttachConnector001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
>> error testClearBreakpoint001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
>> error testMethodEvent001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
>> error
>> testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
>> error testThreadEnd001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
>> error testThreadStart001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>>
>> drlvm-test and drlvm-reg-test are passing.
>>
>> -Nathan
>>
>> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
>> <si...@googlemail.com> wrote:
>> > Hi everyone,
>> >
>> > We have completed a testing cycle for r681495 and evaluated the results
>> [1].
>> >
>> > There are some test failures, but most of them are either intermittent
>> > or were also failing in M6. However if anyone thinks any of these
>> > test failures are blockers and has not yet had a chance to say, please
>> > speak up now.
>> >
>> > Otherwise, shall we declare r681495 as M7?
>> >
>> > Thanks,
>> >
>> > Sian
>> >
>> >
>> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>> >
>> >
>> > --
>> > 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: [vote] Declare r681495 as M7
Posted by chunrong lai <ch...@gmail.com>.
Thanks for the sharing. It is strange that I did not observe the unpack200
failures.
Other classlib failures are not new. The guity commit of the management
failures has been identified as r644719.
The issues in jdktools-test are "timeouts" in our testing. They are not new
either. Moreover the standalone running, for example "java -cp
"/home/laichunrong/apache-ant-1.6.5/lib/junit.jar:./infra/build/checkouts/jdktools/build/tests/classes/"
org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest" just report "OK"
here (should set LD_LIBRARY_PATH to include
./infra/build/checkouts/jdktools/modules/jpda/src/main/native/jdwp/unix/transport).
So
I do not think that they are blockers for now.
Thanks.
On 8/18/08, Nathan Beyer <nd...@apache.org> wrote:
>
> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>
> Here are the failures I'm seeing, consistently, in classlib-test. The
> unpack200 test failures concern me.
>
> error testGetAttribute
> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> error testGetCollectionUsage
>
> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> failure testWithSql
> org.apache.harmony.unpack200.tests.ArchiveTest
> failure
> testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
> failure test_impliesLjava_security_Permission
> tests.api.java.security.PermissionCollectionTest
>
> Here are the failures I'm seeing, consistently, in jdktools-test.
>
> error testDebuggerLaunch001
>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch002
>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch003
>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch004
>
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testAttachConnector001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
> error testClearBreakpoint001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> error testMethodEvent001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
> error
> testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
> error testThreadEnd001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> error testThreadStart001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>
> drlvm-test and drlvm-reg-test are passing.
>
> -Nathan
>
> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> <si...@googlemail.com> wrote:
> > Hi everyone,
> >
> > We have completed a testing cycle for r681495 and evaluated the results
> [1].
> >
> > There are some test failures, but most of them are either intermittent
> > or were also failing in M6. However if anyone thinks any of these
> > test failures are blockers and has not yet had a chance to say, please
> > speak up now.
> >
> > Otherwise, shall we declare r681495 as M7?
> >
> > Thanks,
> >
> > Sian
> >
> >
> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> >
> >
> > --
> > 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: [vote] Declare r681495 as M7
Posted by Sian January <si...@googlemail.com>.
Thanks Mark. I've just reproduced this on my Windows machine by
switching to Sun's Java 6. It's happening because they've changed the
javap format in Java 6 to have some extra blank lines in.
Nathan - I can send you a patch that ignores blank lines in the test
if you would like to confirm this, or I can check it in.
I will try to rewrite these tests to be a bit more robust at some
point before the next milestone because we've had a couple of
situations now where differences in javap output or not having javap
available have caused the tests to fail.
On 19/08/2008, Mark Hindess <ma...@googlemail.com> wrote:
>
> Ok. Using our incomplete javap is probably a bad idea so I've re-run the
> same tests with a sun javap from:
>
> Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
>
> And now I get the same errors as you. Hopefully now Sian can see
> what the problem is.
>
> -Mark.
>
> In message <20...@d06av03.portsmouth.uk.ibm.com>,
> Mark Hindess writes:
> >
> >
> > I've given Sian access to an ubuntu 64-bit machine. However, I get
> > different errors - I'm using a javap from a harmony-5.0-jdk debian
> > package that I'm testing for M7.
> >
> > Nathan, what javap are you using? The output from:
> >
> > update-alternatives --display javap
> >
> > might help. Then I should be able to reproduce your environment more
> > accurately.
> >
> > -Mark
> >
> > In message <fc...@mail.gmail.com>, "Si
> > an
> > January" writes:
> > >
> > > Ok - thanks. I have not seen this before and unfortunately I don't
> > > have access to a 64-bit Ubuntu machine to try it out. It's possibly
> > > happening because your version of javap has a bug in it or prints
> > > things in a different order, but I would need to look at the class
> > > file to find this out.
> > >
> > > Would you be able to run unpack200 manually against HelloWorld.pack
> > > and send me the resulting jar if you have time? HelloWorld.pack is
> > > under pack200/src/test/resources/org/apache/harmony/pack200/tests.
> > >
> > > Thanks,
> > >
> > > Sian
> > >
> > > On 19/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > > Test: testWithSql
> > > > Class: org.apache.harmony.unpack200.tests.ArchiveTest
> > > >
> > > > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > > > but was:<[]>
> > > > at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(Arch
> > iv
> > > eTest.java:94)
> > > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > > Test: testHelloWorld
> > > > Class: org.apache.harmony.unpack200.tests.SegmentTest
> > > >
> > > > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > > > but was:<[]>
> > > > at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(S
> > eg
> > > mentTest.java:125)
> > > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > >
> > > > On Mon, Aug 18, 2008 at 3:07 AM, Sian January
> > > > <si...@googlemail.com> wrote:
> > > > > Nathan - would you mind posting more the failure messages for the
> > > > > unpack200 tests?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Sian
> > > > >
> > > > > On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > > >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
> > > > >>
> > > > >> Here are the failures I'm seeing, consistently, in classlib-test. The
> > > > >> unpack200 test failures concern me.
> > > > >>
> > > > >> error testGetAttribute
> > > > >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> > > > >> error testGetCollectionUsage
> > > > >> org.apache.harmony.lang.management.tests.java.lang.management.M
> > em
> > > oryPoolMXBeanTest
> > > > >> failure testWithSql org.apache.harmony.unpack200.tests.Arc
> > hi
> > > veTest
> > > > >> failure testHelloWorld org.apache.harmony.unpack200.tests.Seg
> > me
> > > ntTest
> > > > >> failure test_impliesLjava_security_Permission
> > > > >> tests.api.java.security.PermissionCollectionTest
> > > > >>
> > > > >> Here are the failures I'm seeing, consistently, in jdktools-test.
> > > > >>
> > > > >> error testDebuggerLaunch001
> > > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> > gg
> > > erLaunchTest
> > > > >> error testDebuggerLaunch002
> > > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> > gg
> > > erLaunchTest
> > > > >> error testDebuggerLaunch003
> > > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> > gg
> > > erLaunchTest
> > > > >> error testDebuggerLaunch004
> > > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> > gg
> > > erLaunchTest
> > > > >> error testAttachConnector001
> > > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnector
> > Te
> > > st
> > > > >> error testClearBreakpoint001
> > > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> > > > >> error testMethodEvent001
> > > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExit
> > Te
> > > st
> > > > >> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSessio
> > n.
> > > ResumeTest
> > > > >> error testThreadEnd001
> > > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> > > > >> error testThreadStart001
> > > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
> > > > >>
> > > > >> drlvm-test and drlvm-reg-test are passing.
> > > > >>
> > > > >> -Nathan
> > > > >>
> > > > >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> > > > >> <si...@googlemail.com> wrote:
> > > > >> > Hi everyone,
> > > > >> >
> > > > >> > We have completed a testing cycle for r681495 and evaluated the resu
> > lt
> > > s [1].
> > > > >> >
> > > > >> > There are some test failures, but most of them are either intermitte
> > nt
> > > > >> > or were also failing in M6. However if anyone thinks any of these
> > > > >> > test failures are blockers and has not yet had a chance to say, plea
> > se
> > > > >> > speak up now.
> > > > >> >
> > > > >> > Otherwise, shall we declare r681495 as M7?
> > > > >> >
> > > > >> > Thanks,
> > > > >> >
> > > > >> > Sian
> > > > >> >
> > > > >> >
> > > > >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Unless stated otherwise above:
> > > > >> > IBM United Kingdom Limited - Registered in England and Wales with nu
> > mb
> > > er 741598.
> > > > >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire P
> > O6
> > > 3AU
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Unless stated otherwise above:
> > > > > IBM United Kingdom Limited - Registered in England and Wales with numbe
> > r
> > > 741598.
> > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3A
> > > U
> > > > >
> > > >
> > >
> > >
> > > --
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with number 74
> > 15
> > > 98.
> > > 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: [vote] Declare r681495 as M7
Posted by Mark Hindess <ma...@googlemail.com>.
Ok. Using our incomplete javap is probably a bad idea so I've re-run the
same tests with a sun javap from:
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
And now I get the same errors as you. Hopefully now Sian can see
what the problem is.
-Mark.
In message <20...@d06av03.portsmouth.uk.ibm.com>,
Mark Hindess writes:
>
>
> I've given Sian access to an ubuntu 64-bit machine. However, I get
> different errors - I'm using a javap from a harmony-5.0-jdk debian
> package that I'm testing for M7.
>
> Nathan, what javap are you using? The output from:
>
> update-alternatives --display javap
>
> might help. Then I should be able to reproduce your environment more
> accurately.
>
> -Mark
>
> In message <fc...@mail.gmail.com>, "Si
> an
> January" writes:
> >
> > Ok - thanks. I have not seen this before and unfortunately I don't
> > have access to a 64-bit Ubuntu machine to try it out. It's possibly
> > happening because your version of javap has a bug in it or prints
> > things in a different order, but I would need to look at the class
> > file to find this out.
> >
> > Would you be able to run unpack200 manually against HelloWorld.pack
> > and send me the resulting jar if you have time? HelloWorld.pack is
> > under pack200/src/test/resources/org/apache/harmony/pack200/tests.
> >
> > Thanks,
> >
> > Sian
> >
> > On 19/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > Test: testWithSql
> > > Class: org.apache.harmony.unpack200.tests.ArchiveTest
> > >
> > > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > > but was:<[]>
> > > at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(Arch
> iv
> > eTest.java:94)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > > Test: testHelloWorld
> > > Class: org.apache.harmony.unpack200.tests.SegmentTest
> > >
> > > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > > but was:<[]>
> > > at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(S
> eg
> > mentTest.java:125)
> > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > >
> > > On Mon, Aug 18, 2008 at 3:07 AM, Sian January
> > > <si...@googlemail.com> wrote:
> > > > Nathan - would you mind posting more the failure messages for the
> > > > unpack200 tests?
> > > >
> > > > Thanks,
> > > >
> > > > Sian
> > > >
> > > > On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > > >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
> > > >>
> > > >> Here are the failures I'm seeing, consistently, in classlib-test. The
> > > >> unpack200 test failures concern me.
> > > >>
> > > >> error testGetAttribute
> > > >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> > > >> error testGetCollectionUsage
> > > >> org.apache.harmony.lang.management.tests.java.lang.management.M
> em
> > oryPoolMXBeanTest
> > > >> failure testWithSql org.apache.harmony.unpack200.tests.Arc
> hi
> > veTest
> > > >> failure testHelloWorld org.apache.harmony.unpack200.tests.Seg
> me
> > ntTest
> > > >> failure test_impliesLjava_security_Permission
> > > >> tests.api.java.security.PermissionCollectionTest
> > > >>
> > > >> Here are the failures I'm seeing, consistently, in jdktools-test.
> > > >>
> > > >> error testDebuggerLaunch001
> > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> gg
> > erLaunchTest
> > > >> error testDebuggerLaunch002
> > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> gg
> > erLaunchTest
> > > >> error testDebuggerLaunch003
> > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> gg
> > erLaunchTest
> > > >> error testDebuggerLaunch004
> > > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebu
> gg
> > erLaunchTest
> > > >> error testAttachConnector001
> > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnector
> Te
> > st
> > > >> error testClearBreakpoint001
> > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> > > >> error testMethodEvent001
> > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExit
> Te
> > st
> > > >> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSessio
> n.
> > ResumeTest
> > > >> error testThreadEnd001
> > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> > > >> error testThreadStart001
> > > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
> > > >>
> > > >> drlvm-test and drlvm-reg-test are passing.
> > > >>
> > > >> -Nathan
> > > >>
> > > >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> > > >> <si...@googlemail.com> wrote:
> > > >> > Hi everyone,
> > > >> >
> > > >> > We have completed a testing cycle for r681495 and evaluated the resu
> lt
> > s [1].
> > > >> >
> > > >> > There are some test failures, but most of them are either intermitte
> nt
> > > >> > or were also failing in M6. However if anyone thinks any of these
> > > >> > test failures are blockers and has not yet had a chance to say, plea
> se
> > > >> > speak up now.
> > > >> >
> > > >> > Otherwise, shall we declare r681495 as M7?
> > > >> >
> > > >> > Thanks,
> > > >> >
> > > >> > Sian
> > > >> >
> > > >> >
> > > >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Unless stated otherwise above:
> > > >> > IBM United Kingdom Limited - Registered in England and Wales with nu
> mb
> > er 741598.
> > > >> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire P
> O6
> > 3AU
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Unless stated otherwise above:
> > > > IBM United Kingdom Limited - Registered in England and Wales with numbe
> r
> > 741598.
> > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3A
> > U
> > > >
> > >
> >
> >
> > --
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number 74
> 15
> > 98.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> >
>
Re: [vote] Declare r681495 as M7
Posted by Sian January <si...@googlemail.com>.
On 20/08/2008, Mark Hindess <ma...@googlemail.com> wrote:
>
> In message <3b...@mail.gmail.com>,
> "Nathan Beyer" writes:
> >
> > nathan:~$ update-alternatives --display javap
> > javap - status is auto.
> > link currently points to /usr/lib/jvm/java-6-sun/bin/javap
> > /usr/lib/jvm/java-6-sun/bin/javap - priority 63
> > slave javap.1.gz: /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
> > Current `best' version is /usr/lib/jvm/java-6-sun/bin/javap.
>
> Hopefully Sian will provide a quick fix for this common case. In the
> meantime, what is you position on M7? Do you think M7 needs a fix for
> this issue? Are there other must-fix issues that you consider blockers?
>
> I would not be unhappy to release r681495 as M7 since these are test
> issues rather than code issues and we have released with failures due
> to bad tests before. So I vote +1 on this thread.
>
> Of course, if Sian can provide a prompt fix for this test issue then she
> has my +1 to commit it and we can start another vote.
>
Thanks Mark - I've checked in a fix for the two tests at r687281.
> > Perhaps using 'javap' isn't the most stable/portable approach. Can we
> > use one of the bytecode libraries we have already and run the class
> > files through that?
>
> I'm sure Sian is considering other options for M8. ;-)
>
Yes - I think I said this yesterday too. I personally don't think
it's worth holding up M7 for since it's a test issue rather than a
code issue, but I will do it if other people think it's important for
M7.
> -Mark
>
>
--
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: [vote] Declare r681495 as M7
Posted by Sian January <si...@googlemail.com>.
+1 from me too
On 20/08/2008, Nathan Beyer <nb...@gmail.com> wrote:
> I'm fine with releasing now. I didn't like that the test results
> couldn't be repeated. Since it was the test itself we can move ahead.
>
> Nathan
>
>
>
> On 8/20/08, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > In message <3b...@mail.gmail.com>,
> > "Nathan Beyer" writes:
> >>
> >> nathan:~$ update-alternatives --display javap
> >> javap - status is auto.
> >> link currently points to /usr/lib/jvm/java-6-sun/bin/javap
> >> /usr/lib/jvm/java-6-sun/bin/javap - priority 63
> >> slave javap.1.gz: /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
> >> Current `best' version is /usr/lib/jvm/java-6-sun/bin/javap.
> >
> > Hopefully Sian will provide a quick fix for this common case. In the
> > meantime, what is you position on M7? Do you think M7 needs a fix for
> > this issue? Are there other must-fix issues that you consider blockers?
> >
> > I would not be unhappy to release r681495 as M7 since these are test
> > issues rather than code issues and we have released with failures due
> > to bad tests before. So I vote +1 on this thread.
> >
> > Of course, if Sian can provide a prompt fix for this test issue then she
> > has my +1 to commit it and we can start another vote.
> >
> >> Perhaps using 'javap' isn't the most stable/portable approach. Can we
> >> use one of the bytecode libraries we have already and run the class
> >> files through that?
> >
> > I'm sure Sian is considering other options for M8. ;-)
> >
> > -Mark
> >
> >
>
> --
> Sent from Gmail for mobile | mobile.google.com
>
--
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: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nb...@gmail.com>.
I'm fine with releasing now. I didn't like that the test results
couldn't be repeated. Since it was the test itself we can move ahead.
Nathan
On 8/20/08, Mark Hindess <ma...@googlemail.com> wrote:
>
> In message <3b...@mail.gmail.com>,
> "Nathan Beyer" writes:
>>
>> nathan:~$ update-alternatives --display javap
>> javap - status is auto.
>> link currently points to /usr/lib/jvm/java-6-sun/bin/javap
>> /usr/lib/jvm/java-6-sun/bin/javap - priority 63
>> slave javap.1.gz: /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
>> Current `best' version is /usr/lib/jvm/java-6-sun/bin/javap.
>
> Hopefully Sian will provide a quick fix for this common case. In the
> meantime, what is you position on M7? Do you think M7 needs a fix for
> this issue? Are there other must-fix issues that you consider blockers?
>
> I would not be unhappy to release r681495 as M7 since these are test
> issues rather than code issues and we have released with failures due
> to bad tests before. So I vote +1 on this thread.
>
> Of course, if Sian can provide a prompt fix for this test issue then she
> has my +1 to commit it and we can start another vote.
>
>> Perhaps using 'javap' isn't the most stable/portable approach. Can we
>> use one of the bytecode libraries we have already and run the class
>> files through that?
>
> I'm sure Sian is considering other options for M8. ;-)
>
> -Mark
>
>
--
Sent from Gmail for mobile | mobile.google.com
Re: [vote] Declare r681495 as M7
Posted by Mark Hindess <ma...@googlemail.com>.
In message <3b...@mail.gmail.com>,
"Nathan Beyer" writes:
>
> nathan:~$ update-alternatives --display javap
> javap - status is auto.
> link currently points to /usr/lib/jvm/java-6-sun/bin/javap
> /usr/lib/jvm/java-6-sun/bin/javap - priority 63
> slave javap.1.gz: /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
> Current `best' version is /usr/lib/jvm/java-6-sun/bin/javap.
Hopefully Sian will provide a quick fix for this common case. In the
meantime, what is you position on M7? Do you think M7 needs a fix for
this issue? Are there other must-fix issues that you consider blockers?
I would not be unhappy to release r681495 as M7 since these are test
issues rather than code issues and we have released with failures due
to bad tests before. So I vote +1 on this thread.
Of course, if Sian can provide a prompt fix for this test issue then she
has my +1 to commit it and we can start another vote.
> Perhaps using 'javap' isn't the most stable/portable approach. Can we
> use one of the bytecode libraries we have already and run the class
> files through that?
I'm sure Sian is considering other options for M8. ;-)
-Mark
Re: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nb...@gmail.com>.
nathan:~$ update-alternatives --display javap
javap - status is auto.
link currently points to /usr/lib/jvm/java-6-sun/bin/javap
/usr/lib/jvm/java-6-sun/bin/javap - priority 63
slave javap.1.gz: /usr/lib/jvm/java-6-sun/man/man1/javap.1.gz
Current `best' version is /usr/lib/jvm/java-6-sun/bin/javap.
Perhaps using 'javap' isn't the most stable/portable approach. Can we
use one of the bytecode libraries we have already and run the class
files through that?
-Nathan
On Tue, Aug 19, 2008 at 8:29 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> I've given Sian access to an ubuntu 64-bit machine. However, I get
> different errors - I'm using a javap from a harmony-5.0-jdk debian
> package that I'm testing for M7.
>
> Nathan, what javap are you using? The output from:
>
> update-alternatives --display javap
>
> might help. Then I should be able to reproduce your environment more
> accurately.
>
> -Mark
>
> In message <fc...@mail.gmail.com>, "Sian
> January" writes:
>>
>> Ok - thanks. I have not seen this before and unfortunately I don't
>> have access to a 64-bit Ubuntu machine to try it out. It's possibly
>> happening because your version of javap has a bug in it or prints
>> things in a different order, but I would need to look at the class
>> file to find this out.
>>
>> Would you be able to run unpack200 manually against HelloWorld.pack
>> and send me the resulting jar if you have time? HelloWorld.pack is
>> under pack200/src/test/resources/org/apache/harmony/pack200/tests.
>>
>> Thanks,
>>
>> Sian
>>
>> On 19/08/2008, Nathan Beyer <nd...@apache.org> wrote:
>> > Test: testWithSql
>> > Class: org.apache.harmony.unpack200.tests.ArchiveTest
>> >
>> > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
>> > but was:<[]>
>> > at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(Archiv
>> eTest.java:94)
>> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> > Test: testHelloWorld
>> > Class: org.apache.harmony.unpack200.tests.SegmentTest
>> >
>> > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
>> > but was:<[]>
>> > at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(Seg
>> mentTest.java:125)
>> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>> >
>> > On Mon, Aug 18, 2008 at 3:07 AM, Sian January
>> > <si...@googlemail.com> wrote:
>> > > Nathan - would you mind posting more the failure messages for the
>> > > unpack200 tests?
>> > >
>> > > Thanks,
>> > >
>> > > Sian
>> > >
>> > > On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
>> > >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>> > >>
>> > >> Here are the failures I'm seeing, consistently, in classlib-test. The
>> > >> unpack200 test failures concern me.
>> > >>
>> > >> error testGetAttribute
>> > >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
>> > >> error testGetCollectionUsage
>> > >> org.apache.harmony.lang.management.tests.java.lang.management.Mem
>> oryPoolMXBeanTest
>> > >> failure testWithSql org.apache.harmony.unpack200.tests.Archi
>> veTest
>> > >> failure testHelloWorld org.apache.harmony.unpack200.tests.Segme
>> ntTest
>> > >> failure test_impliesLjava_security_Permission
>> > >> tests.api.java.security.PermissionCollectionTest
>> > >>
>> > >> Here are the failures I'm seeing, consistently, in jdktools-test.
>> > >>
>> > >> error testDebuggerLaunch001
>> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
>> erLaunchTest
>> > >> error testDebuggerLaunch002
>> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
>> erLaunchTest
>> > >> error testDebuggerLaunch003
>> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
>> erLaunchTest
>> > >> error testDebuggerLaunch004
>> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
>> erLaunchTest
>> > >> error testAttachConnector001
>> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTe
>> st
>> > >> error testClearBreakpoint001
>> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
>> > >> error testMethodEvent001
>> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTe
>> st
>> > >> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.
>> ResumeTest
>> > >> error testThreadEnd001
>> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
>> > >> error testThreadStart001
>> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>> > >>
>> > >> drlvm-test and drlvm-reg-test are passing.
>> > >>
>> > >> -Nathan
>> > >>
>> > >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
>> > >> <si...@googlemail.com> wrote:
>> > >> > Hi everyone,
>> > >> >
>> > >> > We have completed a testing cycle for r681495 and evaluated the result
>> s [1].
>> > >> >
>> > >> > There are some test failures, but most of them are either intermittent
>> > >> > or were also failing in M6. However if anyone thinks any of these
>> > >> > test failures are blockers and has not yet had a chance to say, please
>> > >> > speak up now.
>> > >> >
>> > >> > Otherwise, shall we declare r681495 as M7?
>> > >> >
>> > >> > Thanks,
>> > >> >
>> > >> > Sian
>> > >> >
>> > >> >
>> > >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Unless stated otherwise above:
>> > >> > IBM United Kingdom Limited - Registered in England and Wales with numb
>> er 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 3A
>> U
>> > >
>> >
>>
>>
>> --
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number 7415
>> 98.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>
>
Re: [vote] Declare r681495 as M7
Posted by Mark Hindess <ma...@googlemail.com>.
I've given Sian access to an ubuntu 64-bit machine. However, I get
different errors - I'm using a javap from a harmony-5.0-jdk debian
package that I'm testing for M7.
Nathan, what javap are you using? The output from:
update-alternatives --display javap
might help. Then I should be able to reproduce your environment more
accurately.
-Mark
In message <fc...@mail.gmail.com>, "Sian
January" writes:
>
> Ok - thanks. I have not seen this before and unfortunately I don't
> have access to a 64-bit Ubuntu machine to try it out. It's possibly
> happening because your version of javap has a bug in it or prints
> things in a different order, but I would need to look at the class
> file to find this out.
>
> Would you be able to run unpack200 manually against HelloWorld.pack
> and send me the resulting jar if you have time? HelloWorld.pack is
> under pack200/src/test/resources/org/apache/harmony/pack200/tests.
>
> Thanks,
>
> Sian
>
> On 19/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > Test: testWithSql
> > Class: org.apache.harmony.unpack200.tests.ArchiveTest
> >
> > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > but was:<[]>
> > at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(Archiv
> eTest.java:94)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> > Test: testHelloWorld
> > Class: org.apache.harmony.unpack200.tests.SegmentTest
> >
> > junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> > but was:<[]>
> > at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(Seg
> mentTest.java:125)
> > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> >
> > On Mon, Aug 18, 2008 at 3:07 AM, Sian January
> > <si...@googlemail.com> wrote:
> > > Nathan - would you mind posting more the failure messages for the
> > > unpack200 tests?
> > >
> > > Thanks,
> > >
> > > Sian
> > >
> > > On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> > >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
> > >>
> > >> Here are the failures I'm seeing, consistently, in classlib-test. The
> > >> unpack200 test failures concern me.
> > >>
> > >> error testGetAttribute
> > >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> > >> error testGetCollectionUsage
> > >> org.apache.harmony.lang.management.tests.java.lang.management.Mem
> oryPoolMXBeanTest
> > >> failure testWithSql org.apache.harmony.unpack200.tests.Archi
> veTest
> > >> failure testHelloWorld org.apache.harmony.unpack200.tests.Segme
> ntTest
> > >> failure test_impliesLjava_security_Permission
> > >> tests.api.java.security.PermissionCollectionTest
> > >>
> > >> Here are the failures I'm seeing, consistently, in jdktools-test.
> > >>
> > >> error testDebuggerLaunch001
> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
> erLaunchTest
> > >> error testDebuggerLaunch002
> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
> erLaunchTest
> > >> error testDebuggerLaunch003
> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
> erLaunchTest
> > >> error testDebuggerLaunch004
> > >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebugg
> erLaunchTest
> > >> error testAttachConnector001
> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTe
> st
> > >> error testClearBreakpoint001
> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> > >> error testMethodEvent001
> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTe
> st
> > >> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.
> ResumeTest
> > >> error testThreadEnd001
> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> > >> error testThreadStart001
> > >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
> > >>
> > >> drlvm-test and drlvm-reg-test are passing.
> > >>
> > >> -Nathan
> > >>
> > >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> > >> <si...@googlemail.com> wrote:
> > >> > Hi everyone,
> > >> >
> > >> > We have completed a testing cycle for r681495 and evaluated the result
> s [1].
> > >> >
> > >> > There are some test failures, but most of them are either intermittent
> > >> > or were also failing in M6. However if anyone thinks any of these
> > >> > test failures are blockers and has not yet had a chance to say, please
> > >> > speak up now.
> > >> >
> > >> > Otherwise, shall we declare r681495 as M7?
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Sian
> > >> >
> > >> >
> > >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> > >> >
> > >> >
> > >> > --
> > >> > Unless stated otherwise above:
> > >> > IBM United Kingdom Limited - Registered in England and Wales with numb
> er 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 3A
> U
> > >
> >
>
>
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 7415
> 98.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Re: [vote] Declare r681495 as M7
Posted by Sian January <si...@googlemail.com>.
Ok - thanks. I have not seen this before and unfortunately I don't
have access to a 64-bit Ubuntu machine to try it out. It's possibly
happening because your version of javap has a bug in it or prints
things in a different order, but I would need to look at the class
file to find this out.
Would you be able to run unpack200 manually against HelloWorld.pack
and send me the resulting jar if you have time? HelloWorld.pack is
under pack200/src/test/resources/org/apache/harmony/pack200/tests.
Thanks,
Sian
On 19/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> Test: testWithSql
> Class: org.apache.harmony.unpack200.tests.ArchiveTest
>
> junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> but was:<[]>
> at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(ArchiveTest.java:94)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
> Test: testHelloWorld
> Class: org.apache.harmony.unpack200.tests.SegmentTest
>
> junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
> but was:<[]>
> at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(SegmentTest.java:125)
> at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
>
> On Mon, Aug 18, 2008 at 3:07 AM, Sian January
> <si...@googlemail.com> wrote:
> > Nathan - would you mind posting more the failure messages for the
> > unpack200 tests?
> >
> > Thanks,
> >
> > Sian
> >
> > On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> >> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
> >>
> >> Here are the failures I'm seeing, consistently, in classlib-test. The
> >> unpack200 test failures concern me.
> >>
> >> error testGetAttribute
> >> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> >> error testGetCollectionUsage
> >> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> >> failure testWithSql org.apache.harmony.unpack200.tests.ArchiveTest
> >> failure testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
> >> failure test_impliesLjava_security_Permission
> >> tests.api.java.security.PermissionCollectionTest
> >>
> >> Here are the failures I'm seeing, consistently, in jdktools-test.
> >>
> >> error testDebuggerLaunch001
> >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch002
> >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch003
> >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testDebuggerLaunch004
> >> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> >> error testAttachConnector001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
> >> error testClearBreakpoint001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> >> error testMethodEvent001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
> >> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
> >> error testThreadEnd001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> >> error testThreadStart001
> >> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
> >>
> >> drlvm-test and drlvm-reg-test are passing.
> >>
> >> -Nathan
> >>
> >> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> >> <si...@googlemail.com> wrote:
> >> > Hi everyone,
> >> >
> >> > We have completed a testing cycle for r681495 and evaluated the results [1].
> >> >
> >> > There are some test failures, but most of them are either intermittent
> >> > or were also failing in M6. However if anyone thinks any of these
> >> > test failures are blockers and has not yet had a chance to say, please
> >> > speak up now.
> >> >
> >> > Otherwise, shall we declare r681495 as M7?
> >> >
> >> > Thanks,
> >> >
> >> > Sian
> >> >
> >> >
> >> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> >> >
> >> >
> >> > --
> >> > 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: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nd...@apache.org>.
Test: testWithSql
Class: org.apache.harmony.unpack200.tests.ArchiveTest
junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
but was:<[]>
at org.apache.harmony.unpack200.tests.ArchiveTest.testWithSql(ArchiveTest.java:94)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
Test: testHelloWorld
Class: org.apache.harmony.unpack200.tests.SegmentTest
junit.framework.ComparisonFailure: expected:<[ LocalVariableTable: ]>
but was:<[]>
at org.apache.harmony.unpack200.tests.SegmentTest.testHelloWorld(SegmentTest.java:125)
at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java)
On Mon, Aug 18, 2008 at 3:07 AM, Sian January
<si...@googlemail.com> wrote:
> Nathan - would you mind posting more the failure messages for the
> unpack200 tests?
>
> Thanks,
>
> Sian
>
> On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
>> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>>
>> Here are the failures I'm seeing, consistently, in classlib-test. The
>> unpack200 test failures concern me.
>>
>> error testGetAttribute
>> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
>> error testGetCollectionUsage
>> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
>> failure testWithSql org.apache.harmony.unpack200.tests.ArchiveTest
>> failure testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
>> failure test_impliesLjava_security_Permission
>> tests.api.java.security.PermissionCollectionTest
>>
>> Here are the failures I'm seeing, consistently, in jdktools-test.
>>
>> error testDebuggerLaunch001
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch002
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch003
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testDebuggerLaunch004
>> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
>> error testAttachConnector001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
>> error testClearBreakpoint001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
>> error testMethodEvent001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
>> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
>> error testThreadEnd001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
>> error testThreadStart001
>> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>>
>> drlvm-test and drlvm-reg-test are passing.
>>
>> -Nathan
>>
>> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
>> <si...@googlemail.com> wrote:
>> > Hi everyone,
>> >
>> > We have completed a testing cycle for r681495 and evaluated the results [1].
>> >
>> > There are some test failures, but most of them are either intermittent
>> > or were also failing in M6. However if anyone thinks any of these
>> > test failures are blockers and has not yet had a chance to say, please
>> > speak up now.
>> >
>> > Otherwise, shall we declare r681495 as M7?
>> >
>> > Thanks,
>> >
>> > Sian
>> >
>> >
>> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>> >
>> >
>> > --
>> > 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: [vote] Declare r681495 as M7
Posted by Sian January <si...@googlemail.com>.
Nathan - would you mind posting more the failure messages for the
unpack200 tests?
Thanks,
Sian
On 18/08/2008, Nathan Beyer <nd...@apache.org> wrote:
> -1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
>
> Here are the failures I'm seeing, consistently, in classlib-test. The
> unpack200 test failures concern me.
>
> error testGetAttribute
> org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
> error testGetCollectionUsage
> org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
> failure testWithSql org.apache.harmony.unpack200.tests.ArchiveTest
> failure testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
> failure test_impliesLjava_security_Permission
> tests.api.java.security.PermissionCollectionTest
>
> Here are the failures I'm seeing, consistently, in jdktools-test.
>
> error testDebuggerLaunch001
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch002
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch003
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testDebuggerLaunch004
> org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
> error testAttachConnector001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
> error testClearBreakpoint001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
> error testMethodEvent001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
> error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
> error testThreadEnd001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
> error testThreadStart001
> org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
>
> drlvm-test and drlvm-reg-test are passing.
>
> -Nathan
>
> On Fri, Aug 15, 2008 at 8:26 AM, Sian January
> <si...@googlemail.com> wrote:
> > Hi everyone,
> >
> > We have completed a testing cycle for r681495 and evaluated the results [1].
> >
> > There are some test failures, but most of them are either intermittent
> > or were also failing in M6. However if anyone thinks any of these
> > test failures are blockers and has not yet had a chance to say, please
> > speak up now.
> >
> > Otherwise, shall we declare r681495 as M7?
> >
> > Thanks,
> >
> > Sian
> >
> >
> > [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
> >
> >
> > --
> > 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: [vote] Declare r681495 as M7
Posted by Nathan Beyer <nd...@apache.org>.
-1 I'm not able to reproduce the same results on x86_64 Ubuntu Hardy
Here are the failures I'm seeing, consistently, in classlib-test. The
unpack200 test failures concern me.
error testGetAttribute
org.apache.harmony.lang.management.MemoryPoolMXBeanImplTest
error testGetCollectionUsage
org.apache.harmony.lang.management.tests.java.lang.management.MemoryPoolMXBeanTest
failure testWithSql org.apache.harmony.unpack200.tests.ArchiveTest
failure testHelloWorld org.apache.harmony.unpack200.tests.SegmentTest
failure test_impliesLjava_security_Permission
tests.api.java.security.PermissionCollectionTest
Here are the failures I'm seeing, consistently, in jdktools-test.
error testDebuggerLaunch001
org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
error testDebuggerLaunch002
org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
error testDebuggerLaunch003
org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
error testDebuggerLaunch004
org.apache.harmony.jpda.tests.jdwp.DebuggerOnDemand.OnthrowDebuggerLaunchTest
error testAttachConnector001
org.apache.harmony.jpda.tests.jdwp.MultiSession.AttachConnectorTest
error testClearBreakpoint001
org.apache.harmony.jpda.tests.jdwp.MultiSession.BreakpointTest
error testMethodEvent001
org.apache.harmony.jpda.tests.jdwp.MultiSession.MethodEntryExitTest
error testResume org.apache.harmony.jpda.tests.jdwp.MultiSession.ResumeTest
error testThreadEnd001
org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadEndTest
error testThreadStart001
org.apache.harmony.jpda.tests.jdwp.MultiSession.ThreadStartTest
drlvm-test and drlvm-reg-test are passing.
-Nathan
On Fri, Aug 15, 2008 at 8:26 AM, Sian January
<si...@googlemail.com> wrote:
> Hi everyone,
>
> We have completed a testing cycle for r681495 and evaluated the results [1].
>
> There are some test failures, but most of them are either intermittent
> or were also failing in M6. However if anyone thinks any of these
> test failures are blockers and has not yet had a chance to say, please
> speak up now.
>
> Otherwise, shall we declare r681495 as M7?
>
> Thanks,
>
> Sian
>
>
> [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>
>
> --
> 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: [vote] Declare r681495 as M7
Posted by chunrong lai <ch...@gmail.com>.
+1
On 8/15/08, Oliver Deakin <ol...@googlemail.com> wrote:
>
> +1 to declaring M7 at r681495.
>
> Regards,
> Oliver
>
> Sian January wrote:
>
>> Hi everyone,
>>
>> We have completed a testing cycle for r681495 and evaluated the results
>> [1].
>>
>> There are some test failures, but most of them are either intermittent
>> or were also failing in M6. However if anyone thinks any of these
>> test failures are blockers and has not yet had a chance to say, please
>> speak up now.
>>
>> Otherwise, shall we declare r681495 as M7?
>>
>> Thanks,
>>
>> Sian
>>
>>
>> [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>>
>>
>>
>>
>
> --
> Oliver Deakin
> 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: [vote] Declare r681495 as M7
Posted by Oliver Deakin <ol...@googlemail.com>.
+1 to declaring M7 at r681495.
Regards,
Oliver
Sian January wrote:
> Hi everyone,
>
> We have completed a testing cycle for r681495 and evaluated the results [1].
>
> There are some test failures, but most of them are either intermittent
> or were also failing in M6. However if anyone thinks any of these
> test failures are blockers and has not yet had a chance to say, please
> speak up now.
>
> Otherwise, shall we declare r681495 as M7?
>
> Thanks,
>
> Sian
>
>
> [1] http://harmony.markmail.org/message/cpfcnslv53doueeg?q=
>
>
>
--
Oliver Deakin
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