You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2008/08/19 15:29:27 UTC
Re: [vote] Declare r681495 as M7
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>.
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
>>
>
>