You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2010/09/21 23:33:43 UTC
Request for testing help
I'm testing my new TaskManager the , but I have some anomalies. It would
help me to get some more testing of
https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager
done in other WindowsXP environments.
Both the head revision and revision 998737 need to be tested. Revision
998737 is the one I plan to merge into the trunk. It changes the
interface between TaskManager and its callers, with minimal changes to
TaskManager.
It is important that it be tested widely, because it affects a lot of
critical classes, and would be difficult to back out.
The head revision drops in a revised TaskManager. It should be easy to
back out if necessary.
Patricia
Re: Request for testing help
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia Shanahan wrote:
> YES, PLEASE! Code reviews are a good thing in any case, and this is my
> first open source, Apache, or River coding effort, so there may be
> style issues.
Actually, all the code you've written so far has been readable and
understandable. Hope you enjoy your vacation.
Cheers,
Peter.
>
> My big picture objective is to improve the scalability of TaskManager,
> as a response to https://issues.apache.org/jira/browse/RIVER-344.
>
> It was doing a lot of O(n) operations, mainly due to the use of an
> ArrayList to represent essentially a FIFO. Those O(n) operations are
> doubly bad news for scalability because they are done under
> synchronization. I've reduced many of them to O(log n) by replacing
> the ArrayList with a TreeSet and PriorityBlockingQueue, both in order
> of arrival, the same order as the original ArrayList.
>
> I may implement finer scale optimizations later, such as replacing
> synchronization with atomic operations. However, in my experience it
> is important to get the data structures and algorithms right first.
>
> Unfortunately, as far as I can tell, even with Jonathan's heroic
> test-enabling efforts, I don't think we have a good TaskManager
> scalability test, or a test of the concurrent behavior of its clients.
>
> Patricia
>
>
> On 9/22/2010 7:16 AM, Tom Hobbs wrote:
>> I'm happy to do some code reviews. I can't run any tests though, I
>> don't
>> have any access to any Windows machines.
>>
>> Let me know if this would be useful, and I'll check those revisions out.
>>
>> On Tue, Sep 21, 2010 at 10:33 PM, Patricia Shanahan<pa...@acm.org>
>> wrote:
>>
>>> I'm testing my new TaskManager the , but I have some anomalies. It
>>> would
>>> help me to get some more testing of
>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone
>>> in other WindowsXP environments.
>>>
>>> Both the head revision and revision 998737 need to be tested. Revision
>>> 998737 is the one I plan to merge into the trunk. It changes the
>>> interface
>>> between TaskManager and its callers, with minimal changes to
>>> TaskManager.
>>>
>>> It is important that it be tested widely, because it affects a lot of
>>> critical classes, and would be difficult to back out.
>>>
>>> The head revision drops in a revised TaskManager. It should be easy
>>> to back
>>> out if necessary.
>>>
>>> Patricia
>>>
>>
>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I've already started on TaskManager testing and benchmarking in
isolation. My next sub-project will be to work on that some more.
I also want to construct unit tests of the more complicated TaskManager
clients, JoinManager and ServiceDiscoveryManager. I'm particularly
concerned about retries of those RetryTask subclasses that are involved
in runAfter dependencies. The last time I checked, we were getting one
instance of that in the whole QA suite, nowhere near enough.
Patricia
Jonathan Costers wrote:
> I will test the revision you requested on Windows later tonight.
> It'll take a while though, as you are aware.
>
> Actually, I noticed that a lot of the service QA tests contain code that
> uses TaskManager, so I think by running the complete QA suite, you are
> implicitely testing TaskManager.
> I haven't looked into it too deep, but that was my impression going through
> the tests (fixing javadoc tags, lol)
>
> It would be great, however, to have (a/some) unit test(s) that test
> TaskManager behaviour in isolation as well. I know, its not that straight
> forward ... But still it would be great :-)
>
> 2010/9/22 Patricia Shanahan <pa...@acm.org>
>
>> YES, PLEASE! Code reviews are a good thing in any case, and this is my
>> first open source, Apache, or River coding effort, so there may be style
>> issues.
>>
>> My big picture objective is to improve the scalability of TaskManager, as a
>> response to https://issues.apache.org/jira/browse/RIVER-344.
>>
>> It was doing a lot of O(n) operations, mainly due to the use of an
>> ArrayList to represent essentially a FIFO. Those O(n) operations are doubly
>> bad news for scalability because they are done under synchronization. I've
>> reduced many of them to O(log n) by replacing the ArrayList with a TreeSet
>> and PriorityBlockingQueue, both in order of arrival, the same order as the
>> original ArrayList.
>>
>> I may implement finer scale optimizations later, such as replacing
>> synchronization with atomic operations. However, in my experience it is
>> important to get the data structures and algorithms right first.
>>
>> Unfortunately, as far as I can tell, even with Jonathan's heroic
>> test-enabling efforts, I don't think we have a good TaskManager scalability
>> test, or a test of the concurrent behavior of its clients.
>>
>> Patricia
>>
>>
>>
>> On 9/22/2010 7:16 AM, Tom Hobbs wrote:
>>
>>> I'm happy to do some code reviews. I can't run any tests though, I don't
>>> have any access to any Windows machines.
>>>
>>> Let me know if this would be useful, and I'll check those revisions out.
>>>
>>> On Tue, Sep 21, 2010 at 10:33 PM, Patricia Shanahan<pa...@acm.org> wrote:
>>>
>>> I'm testing my new TaskManager the , but I have some anomalies. It would
>>>> help me to get some more testing of
>>>>
>>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdonein other WindowsXP environments.
>>>>
>>>> Both the head revision and revision 998737 need to be tested. Revision
>>>> 998737 is the one I plan to merge into the trunk. It changes the
>>>> interface
>>>> between TaskManager and its callers, with minimal changes to TaskManager.
>>>>
>>>> It is important that it be tested widely, because it affects a lot of
>>>> critical classes, and would be difficult to back out.
>>>>
>>>> The head revision drops in a revised TaskManager. It should be easy to
>>>> back
>>>> out if necessary.
>>>>
>>>> Patricia
>>>>
>>>>
>
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
I will test the revision you requested on Windows later tonight.
It'll take a while though, as you are aware.
Actually, I noticed that a lot of the service QA tests contain code that
uses TaskManager, so I think by running the complete QA suite, you are
implicitely testing TaskManager.
I haven't looked into it too deep, but that was my impression going through
the tests (fixing javadoc tags, lol)
It would be great, however, to have (a/some) unit test(s) that test
TaskManager behaviour in isolation as well. I know, its not that straight
forward ... But still it would be great :-)
2010/9/22 Patricia Shanahan <pa...@acm.org>
> YES, PLEASE! Code reviews are a good thing in any case, and this is my
> first open source, Apache, or River coding effort, so there may be style
> issues.
>
> My big picture objective is to improve the scalability of TaskManager, as a
> response to https://issues.apache.org/jira/browse/RIVER-344.
>
> It was doing a lot of O(n) operations, mainly due to the use of an
> ArrayList to represent essentially a FIFO. Those O(n) operations are doubly
> bad news for scalability because they are done under synchronization. I've
> reduced many of them to O(log n) by replacing the ArrayList with a TreeSet
> and PriorityBlockingQueue, both in order of arrival, the same order as the
> original ArrayList.
>
> I may implement finer scale optimizations later, such as replacing
> synchronization with atomic operations. However, in my experience it is
> important to get the data structures and algorithms right first.
>
> Unfortunately, as far as I can tell, even with Jonathan's heroic
> test-enabling efforts, I don't think we have a good TaskManager scalability
> test, or a test of the concurrent behavior of its clients.
>
> Patricia
>
>
>
> On 9/22/2010 7:16 AM, Tom Hobbs wrote:
>
>> I'm happy to do some code reviews. I can't run any tests though, I don't
>> have any access to any Windows machines.
>>
>> Let me know if this would be useful, and I'll check those revisions out.
>>
>> On Tue, Sep 21, 2010 at 10:33 PM, Patricia Shanahan<pa...@acm.org> wrote:
>>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>>> help me to get some more testing of
>>>
>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdonein other WindowsXP environments.
>>>
>>> Both the head revision and revision 998737 need to be tested. Revision
>>> 998737 is the one I plan to merge into the trunk. It changes the
>>> interface
>>> between TaskManager and its callers, with minimal changes to TaskManager.
>>>
>>> It is important that it be tested widely, because it affects a lot of
>>> critical classes, and would be difficult to back out.
>>>
>>> The head revision drops in a revised TaskManager. It should be easy to
>>> back
>>> out if necessary.
>>>
>>> Patricia
>>>
>>>
>>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
YES, PLEASE! Code reviews are a good thing in any case, and this is my
first open source, Apache, or River coding effort, so there may be style
issues.
My big picture objective is to improve the scalability of TaskManager,
as a response to https://issues.apache.org/jira/browse/RIVER-344.
It was doing a lot of O(n) operations, mainly due to the use of an
ArrayList to represent essentially a FIFO. Those O(n) operations are
doubly bad news for scalability because they are done under
synchronization. I've reduced many of them to O(log n) by replacing the
ArrayList with a TreeSet and PriorityBlockingQueue, both in order of
arrival, the same order as the original ArrayList.
I may implement finer scale optimizations later, such as replacing
synchronization with atomic operations. However, in my experience it is
important to get the data structures and algorithms right first.
Unfortunately, as far as I can tell, even with Jonathan's heroic
test-enabling efforts, I don't think we have a good TaskManager
scalability test, or a test of the concurrent behavior of its clients.
Patricia
On 9/22/2010 7:16 AM, Tom Hobbs wrote:
> I'm happy to do some code reviews. I can't run any tests though, I don't
> have any access to any Windows machines.
>
> Let me know if this would be useful, and I'll check those revisions out.
>
> On Tue, Sep 21, 2010 at 10:33 PM, Patricia Shanahan<pa...@acm.org> wrote:
>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>> help me to get some more testing of
>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>>
>> Both the head revision and revision 998737 need to be tested. Revision
>> 998737 is the one I plan to merge into the trunk. It changes the interface
>> between TaskManager and its callers, with minimal changes to TaskManager.
>>
>> It is important that it be tested widely, because it affects a lot of
>> critical classes, and would be difficult to back out.
>>
>> The head revision drops in a revised TaskManager. It should be easy to back
>> out if necessary.
>>
>> Patricia
>>
>
Re: Request for testing help
Posted by Tom Hobbs <tv...@googlemail.com>.
I'm happy to do some code reviews. I can't run any tests though, I don't
have any access to any Windows machines.
Let me know if this would be useful, and I'll check those revisions out.
On Tue, Sep 21, 2010 at 10:33 PM, Patricia Shanahan <pa...@acm.org> wrote:
> I'm testing my new TaskManager the , but I have some anomalies. It would
> help me to get some more testing of
> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>
> Both the head revision and revision 998737 need to be tested. Revision
> 998737 is the one I plan to merge into the trunk. It changes the interface
> between TaskManager and its callers, with minimal changes to TaskManager.
>
> It is important that it be tested widely, because it affects a lot of
> critical classes, and would be difficult to back out.
>
> The head revision drops in a revised TaskManager. It should be easy to back
> out if necessary.
>
> Patricia
>
Re: Request for testing help
Posted by Peter Firmstone <ji...@zeus.net.au>.
I'll checkout and run this on my old bomb, slower separate socket
processors might help flush this out.
Peter.
Patricia Shanahan wrote:
> On 9/24/2010 2:01 PM, Patricia Shanahan wrote:
>> On 9/23/2010 6:15 AM, Tom Hobbs wrote:
>>> Maybe this is a red herring, but it's nothing to do with your use of
>>> OpenJDK, is it? Are we restricted to the Sun JDK?
>>
>> For the last couple of days, I've been setting up VirtualBox
>> environments to run this test continuously. I just got a failure on an
>> OpenSolaris using only the Sun JDK - no OpenJDK installed.
>>
>> This eliminates the theory that it is related to OpenJDK vs. Sun JDK. I
>> am more convinced than ever that this test either itself contains a low
>> frequency concurrency bug or brings out a low frequency concurrency bug
>> in River.
>>
>> Unfortunately, the failure rate is inconveniently low. This failure was
>> preceded by 1613 consecutive passes, taking over 13 hours. I have
>> tracked down problems with lower failure rates, but it can be a slow
>> process.
>
> I have also got one failure in 3772 runs under Ubuntu with the Sun
> JDK. I think it is averaging about one failure per 2000 runs.
>
>
> [java] ENVIRONMENT PROPERTIES:
> [java]
> [java] JVM information:
> [java] Java HotSpot(TM) Client VM, 17.0-b16, 32 bit VM mode
> [java] Sun Microsystems Inc.
> [java] OS information:
> [java] Linux, 2.6.32-21-generic, i386
> [java]
> [java] -----------------------------------------
> [java] STARTING TO RUN THE TESTS
> [java]
> [java]
> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java] Time is Fri Sep 24 12:08:15 PDT 2010
> [java] Starting test in separate process with command:
> [java] /usr/jdk/jdk1.6.0_21/jre/bin/java
> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
> -cp
> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
> -client
> -Djava.ext.dirs=/usr/jdk/jdk1.6.0_21/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
> -Dcom.sun.jini.jsk.home=/home/pats/River
> -Dcom.sun.jini.qa.home=/home/pats/River/qa
> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
> -Dcom.sun.jini.qa.harness.runjiniserver=true
> -Dcom.sun.jini.qa.harness.runkitserver=true
> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
> -Dcom.sun.jini.qa.harness.testhosts=
> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
> -Dcom.sun.jini.test.home=/home/pats/River/qa
> -Dcom.sun.jini.test.port=8082
> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
> -Djava.ext.dirs=/usr/jdk/jdk1.6.0_21/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> com.sun.jini.qa.harness.MasterTest
> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java]
> [java] TIME: 12:08:16 PM
> [java]
> [java] MasterTest.doTest INFO:
> [java] ============================== CALLING SETUP()
> ==============================
> [java]
> [java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/],
> port 8081]
> [java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/],
> port 8080]
> [java] MasterTest.doTest INFO:
> [java] =============================== CALLING RUN()
> ===============================
> [java]
> [java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/],
> port 8082]
> [java] NonActGrp-out: Sep 24, 2010 12:08:17 PM
> com.sun.jini.reggie.RegistrarImpl init
> [java] NonActGrp-out: INFO: started Reggie:
> d7a3752e-1a6b-4941-9e74-cb75c71a4430,
> [LDSLookupServiceGroup_Verify2_1285355295530],
> ConstrainableLookupLocator[[jini://Verify2/], [null]]
> [java] NonActGrp-out: Sep 24, 2010 12:08:18 PM
> com.sun.jini.mercury.MailboxImpl doInit
> [java] NonActGrp-out: INFO: Mercury started:
> com.sun.jini.mercury.TransientMercuryImpl@18f51f
> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
> PullEventMailbox service:
> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@178efc09
> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
> MailboxPullRegistration object:
> com.sun.jini.mercury.Registration$ConstrainableRegistration@d17f8d9
> [java] MailboxTestBase.getPullRegistration INFO: registration
> proxy preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullRegistration INFO: Prepared
> registration proxy:
> com.sun.jini.mercury.Registration$ConstrainableRegistration@d17f8d9
> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
> getPullMailboxLease()
> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox
> lease preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared
> mailbox lease proxy:
> LandlordLease:6f1578f8-3e9e-4fd4-b948-0610e5d4c9e5
> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[99d45127-9a1e-49d4-a206-4712eed82c29,TcpEndpoint[127.0.1.1:53284]]]]
> landlordUuid:acaa7a0f-9fc7-47a4-bd02-ea5699e12bf4
> com.sun.jini.landlord.ConstrainableLandlordLease@d17f8d9
> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> granted
> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilFri Sep 24
> 12:11:18 PDT 2010
> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
> getPullMailboxListener()
> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
> listener preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
> mailbox listener proxy:
> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@d17f8d9
> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> granted
> [java] MailboxTestUtils: createPullListeners: created 1
> TestPullListener(s)
> [java] EMSRIFT_PULL.run INFO: Generating 5 events
> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
> [java] java.rmi.ServerException: RemoteException in server
> thread; nested exception is:
> [java] java.rmi.NoSuchObjectException: Requested registration
> objecthas expired
> [java] at
> net.jini.jeri.BasicInvocationDispatcher.dispatch(Unknown Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target$2.run(Unknown
> Source)
> [java] at
> net.jini.export.ServerContext.doWithServerContext(Unknown Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch0(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.access$700(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target$1.run(Unknown
> Source)
> [java] at
> com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(Unknown
> Source)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$RD.dispatch(Unknown
> Source)
> [java] at
> net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.mux.MuxServer$1$1.run(Unknown Source)
> [java] at
> com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$1.run(Unknown
> Source)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at
> com.sun.jini.jeri.internal.mux.MuxServer$1.run(Unknown Source)
> [java] at com.sun.jini.thread.ThreadPool$Worker.run(Unknown
> Source)
> [java] at java.lang.Thread.run(Thread.java:619)
> [java] at
> com.sun.jini.jeri.internal.runtime.Util.__________EXCEPTION_RECEIVED_FROM_SERVER__________(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.Util.exceptionReceivedFromServer(Unknown
> Source)
> [java] at
> net.jini.jeri.BasicInvocationHandler.unmarshalThrow(Unknown Source)
> [java] at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Unknown
> Source)
> [java] at
> net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(Unknown Source)
> [java] at net.jini.jeri.BasicInvocationHandler.invoke(Unknown
> Source)
> [java] at $Proxy3.getRemoteEvents(Unknown Source)
> [java] at
> com.sun.jini.test.impl.mercury.EMSTestBase.getCollectedRemoteEvents(Unknown
> Source)
> [java] at
> com.sun.jini.test.spec.eventmailbox.EMSRIFT_PULL.run(Unknown Source)
> [java] at com.sun.jini.qa.harness.MasterTest.doTest(Unknown
> Source)
> [java] at com.sun.jini.qa.harness.MasterTest.main(Unknown
> Source)
> [java] Caused by: java.rmi.NoSuchObjectException: Requested
> registration objecthas expired
> [java] at
> com.sun.jini.mercury.MailboxImpl.getServiceRegistration(Unknown Source)
> [java] at
> com.sun.jini.mercury.MailboxImpl.validateIterator(Unknown Source)
> [java] at
> com.sun.jini.mercury.MailboxImpl.getNextBatchDo(Unknown Source)
> [java] at
> com.sun.jini.mercury.MailboxImpl.getNextBatch(Unknown Source)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> [java] at java.lang.reflect.Method.invoke(Method.java:597)
> [java] at
> net.jini.jeri.BasicInvocationDispatcher.invoke(Unknown Source)
> [java] at
> net.jini.jeri.BasicInvocationDispatcher.dispatch(Unknown Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target$2.run(Unknown
> Source)
> [java] at
> net.jini.export.ServerContext.doWithServerContext(Unknown Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch0(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.access$700(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target$1.run(Unknown
> Source)
> [java] at
> com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(Unknown
> Source)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.runtime.ObjectTable$RD.dispatch(Unknown
> Source)
> [java] at
> net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(Unknown
> Source)
> [java] at
> com.sun.jini.jeri.internal.mux.MuxServer$1$1.run(Unknown Source)
> [java] at
> com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$1.run(Unknown
> Source)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at
> com.sun.jini.jeri.internal.mux.MuxServer$1.run(Unknown Source)
> [java] at com.sun.jini.thread.ThreadPool$Worker.run(Unknown
> Source)
> [java] at java.lang.Thread.run(Thread.java:619)
> [java]
> [java] TIME: 12:29:27 PM
> [java]
> [java] MasterTest.doTest INFO:
> [java] ============================ CALLING TEARDOWN()
> =============================
> [java]
> [java] NonActGrp-out: Sep 24, 2010 12:29:27 PM
> com.sun.jini.reggie.RegistrarImpl destroy
> [java] NonActGrp-out: INFO: starting Reggie shutdown
> [java] NonActGrp-out: Sep 24, 2010 12:29:27 PM
> com.sun.jini.reggie.RegistrarImpl$DestroyThread run
> [java] NonActGrp-out: INFO: Reggie shutdown completed
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8081]
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8082]
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8081]
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8080]
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8080]
> [java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
> terminate
> [java] INFO: ClassServer terminated [port 8082]
> [java]
> [java] TIME: 12:29:29 PM
> [java]
> [java] Test process was destroyed and returned code 1
> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java] Test Failed: Test Failed with an Unexpected Exception:
> java.rmi.ServerException: RemoteException in server thread; nested
> exception is:
> [java] java.rmi.NoSuchObjectException: Requested registration
> objecthas expired
> [java]
> [java]
> [java] -----------------------------------------
> [java]
> [java] SUMMARY =================================
> [java]
> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java] Test Failed: Test Failed with an Unexpected Exception:
> java.rmi.ServerException: RemoteException in server thread; nested
> exception is:
> [java] java.rmi.NoSuchObjectException: Requested registration
> objecthas expired
> [java]
> [java] -----------------------------------------
> [java]
> [java] # of tests started = 1
> [java] # of tests completed = 1
> [java] # of tests passed = 0
> [java] # of tests failed = 1
> [java]
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/24/2010 2:01 PM, Patricia Shanahan wrote:
> On 9/23/2010 6:15 AM, Tom Hobbs wrote:
>> Maybe this is a red herring, but it's nothing to do with your use of
>> OpenJDK, is it? Are we restricted to the Sun JDK?
>
> For the last couple of days, I've been setting up VirtualBox
> environments to run this test continuously. I just got a failure on an
> OpenSolaris using only the Sun JDK - no OpenJDK installed.
>
> This eliminates the theory that it is related to OpenJDK vs. Sun JDK. I
> am more convinced than ever that this test either itself contains a low
> frequency concurrency bug or brings out a low frequency concurrency bug
> in River.
>
> Unfortunately, the failure rate is inconveniently low. This failure was
> preceded by 1613 consecutive passes, taking over 13 hours. I have
> tracked down problems with lower failure rates, but it can be a slow
> process.
I have also got one failure in 3772 runs under Ubuntu with the Sun JDK.
I think it is averaging about one failure per 2000 runs.
[java] ENVIRONMENT PROPERTIES:
[java]
[java] JVM information:
[java] Java HotSpot(TM) Client VM, 17.0-b16, 32 bit VM mode
[java] Sun Microsystems Inc.
[java] OS information:
[java] Linux, 2.6.32-21-generic, i386
[java]
[java] -----------------------------------------
[java] STARTING TO RUN THE TESTS
[java]
[java]
[java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Time is Fri Sep 24 12:08:15 PDT 2010
[java] Starting test in separate process with command:
[java] /usr/jdk/jdk1.6.0_21/jre/bin/java
-Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
-cp
/home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
-client
-Djava.ext.dirs=/usr/jdk/jdk1.6.0_21/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
-Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
-Dcom.sun.jini.jsk.home=/home/pats/River
-Dcom.sun.jini.qa.home=/home/pats/River/qa
-Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
-Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
-Dcom.sun.jini.qa.harness.runjiniserver=true
-Dcom.sun.jini.qa.harness.runkitserver=true
-Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
-Dcom.sun.jini.qa.harness.testhosts=
-Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
-Dcom.sun.jini.test.home=/home/pats/River/qa
-Dcom.sun.jini.test.port=8082
-Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
-Djava.ext.dirs=/usr/jdk/jdk1.6.0_21/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
com.sun.jini.qa.harness.MasterTest
com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java]
[java] TIME: 12:08:16 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================== CALLING SETUP()
==============================
[java]
[java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
8081]
[java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
8080]
[java] MasterTest.doTest INFO:
[java] =============================== CALLING RUN()
===============================
[java]
[java] Sep 24, 2010 12:08:16 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
8082]
[java] NonActGrp-out: Sep 24, 2010 12:08:17 PM
com.sun.jini.reggie.RegistrarImpl init
[java] NonActGrp-out: INFO: started Reggie:
d7a3752e-1a6b-4941-9e74-cb75c71a4430,
[LDSLookupServiceGroup_Verify2_1285355295530],
ConstrainableLookupLocator[[jini://Verify2/], [null]]
[java] NonActGrp-out: Sep 24, 2010 12:08:18 PM
com.sun.jini.mercury.MailboxImpl doInit
[java] NonActGrp-out: INFO: Mercury started:
com.sun.jini.mercury.TransientMercuryImpl@18f51f
[java] MailboxTestBase.getPullMailbox INFO: Got reference to
PullEventMailbox service:
com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@178efc09
[java] MailboxTestBase.getPullRegistration INFO: Got reference to
MailboxPullRegistration object:
com.sun.jini.mercury.Registration$ConstrainableRegistration@d17f8d9
[java] MailboxTestBase.getPullRegistration INFO: registration
proxy preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullRegistration INFO: Prepared
registration proxy:
com.sun.jini.mercury.Registration$ConstrainableRegistration@d17f8d9
[java] MailboxTestBase.getPullMailboxLease INFO: Calling
getPullMailboxLease()
[java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
lease proxy: LandlordLease:6f1578f8-3e9e-4fd4-b948-0610e5d4c9e5
landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[99d45127-9a1e-49d4-a206-4712eed82c29,TcpEndpoint[127.0.1.1:53284]]]]
landlordUuid:acaa7a0f-9fc7-47a4-bd02-ea5699e12bf4
com.sun.jini.landlord.ConstrainableLandlordLease@d17f8d9
[java] MailboxTestBase.checkLease INFO: Lease request for 180000
granted
[java] EMSRIFT_PULL.run INFO: Mailbox lease good untilFri Sep 24
12:11:18 PDT 2010
[java] MailboxTestBase.getPullMailboxListener INFO: Calling
getPullMailboxListener()
[java] MailboxTestBase.getPullMailboxListener INFO: mailbox
listener preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullMailboxListener INFO: Prepared
mailbox listener proxy:
com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@d17f8d9
[java] MailboxTestBase.checkLease INFO: Lease request for 180000
granted
[java] MailboxTestUtils: createPullListeners: created 1
TestPullListener(s)
[java] EMSRIFT_PULL.run INFO: Generating 5 events
[java] EMSRIFT_PULL.run INFO: Wating for event delivery
[java] java.rmi.ServerException: RemoteException in server thread;
nested exception is:
[java] java.rmi.NoSuchObjectException: Requested registration
objecthas expired
[java] at
net.jini.jeri.BasicInvocationDispatcher.dispatch(Unknown Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target$2.run(Unknown Source)
[java] at
net.jini.export.ServerContext.doWithServerContext(Unknown Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch0(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.access$700(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target$1.run(Unknown Source)
[java] at
com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(Unknown
Source)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$RD.dispatch(Unknown Source)
[java] at
net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.mux.MuxServer$1$1.run(Unknown Source)
[java] at
com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$1.run(Unknown
Source)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at com.sun.jini.jeri.internal.mux.MuxServer$1.run(Unknown
Source)
[java] at com.sun.jini.thread.ThreadPool$Worker.run(Unknown Source)
[java] at java.lang.Thread.run(Thread.java:619)
[java] at
com.sun.jini.jeri.internal.runtime.Util.__________EXCEPTION_RECEIVED_FROM_SERVER__________(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.Util.exceptionReceivedFromServer(Unknown
Source)
[java] at
net.jini.jeri.BasicInvocationHandler.unmarshalThrow(Unknown Source)
[java] at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(Unknown Source)
[java] at
net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(Unknown Source)
[java] at net.jini.jeri.BasicInvocationHandler.invoke(Unknown Source)
[java] at $Proxy3.getRemoteEvents(Unknown Source)
[java] at
com.sun.jini.test.impl.mercury.EMSTestBase.getCollectedRemoteEvents(Unknown
Source)
[java] at
com.sun.jini.test.spec.eventmailbox.EMSRIFT_PULL.run(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.doTest(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.main(Unknown Source)
[java] Caused by: java.rmi.NoSuchObjectException: Requested
registration objecthas expired
[java] at
com.sun.jini.mercury.MailboxImpl.getServiceRegistration(Unknown Source)
[java] at
com.sun.jini.mercury.MailboxImpl.validateIterator(Unknown Source)
[java] at com.sun.jini.mercury.MailboxImpl.getNextBatchDo(Unknown
Source)
[java] at com.sun.jini.mercury.MailboxImpl.getNextBatch(Unknown
Source)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at net.jini.jeri.BasicInvocationDispatcher.invoke(Unknown
Source)
[java] at
net.jini.jeri.BasicInvocationDispatcher.dispatch(Unknown Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target$2.run(Unknown Source)
[java] at
net.jini.export.ServerContext.doWithServerContext(Unknown Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch0(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.access$700(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target$1.run(Unknown Source)
[java] at
com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$2.run(Unknown
Source)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$Target.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.runtime.ObjectTable$RD.dispatch(Unknown Source)
[java] at
net.jini.jeri.connection.ServerConnectionManager$Dispatcher.dispatch(Unknown
Source)
[java] at
com.sun.jini.jeri.internal.mux.MuxServer$1$1.run(Unknown Source)
[java] at
com.sun.jini.start.AggregatePolicyProvider$AggregateSecurityContext$1.run(Unknown
Source)
[java] at java.security.AccessController.doPrivileged(Native Method)
[java] at com.sun.jini.jeri.internal.mux.MuxServer$1.run(Unknown
Source)
[java] at com.sun.jini.thread.ThreadPool$Worker.run(Unknown Source)
[java] at java.lang.Thread.run(Thread.java:619)
[java]
[java] TIME: 12:29:27 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================ CALLING TEARDOWN()
=============================
[java]
[java] NonActGrp-out: Sep 24, 2010 12:29:27 PM
com.sun.jini.reggie.RegistrarImpl destroy
[java] NonActGrp-out: INFO: starting Reggie shutdown
[java] NonActGrp-out: Sep 24, 2010 12:29:27 PM
com.sun.jini.reggie.RegistrarImpl$DestroyThread run
[java] NonActGrp-out: INFO: Reggie shutdown completed
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8081]
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8082]
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8081]
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8080]
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8080]
[java] Sep 24, 2010 12:29:29 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8082]
[java]
[java] TIME: 12:29:29 PM
[java]
[java] Test process was destroyed and returned code 1
[java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Test Failed: Test Failed with an Unexpected Exception:
java.rmi.ServerException: RemoteException in server thread; nested
exception is:
[java] java.rmi.NoSuchObjectException: Requested registration
objecthas expired
[java]
[java]
[java] -----------------------------------------
[java]
[java] SUMMARY =================================
[java]
[java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Test Failed: Test Failed with an Unexpected Exception:
java.rmi.ServerException: RemoteException in server thread; nested
exception is:
[java] java.rmi.NoSuchObjectException: Requested registration
objecthas expired
[java]
[java] -----------------------------------------
[java]
[java] # of tests started = 1
[java] # of tests completed = 1
[java] # of tests passed = 0
[java] # of tests failed = 1
[java]
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/23/2010 6:15 AM, Tom Hobbs wrote:
> Maybe this is a red herring, but it's nothing to do with your use of
> OpenJDK, is it? Are we restricted to the Sun JDK?
For the last couple of days, I've been setting up VirtualBox
environments to run this test continuously. I just got a failure on an
OpenSolaris using only the Sun JDK - no OpenJDK installed.
This eliminates the theory that it is related to OpenJDK vs. Sun JDK. I
am more convinced than ever that this test either itself contains a low
frequency concurrency bug or brings out a low frequency concurrency bug
in River.
Unfortunately, the failure rate is inconveniently low. This failure was
preceded by 1613 consecutive passes, taking over 13 hours. I have
tracked down problems with lower failure rates, but it can be a slow
process.
Patricia
[java] -----------------------------------------
[java] GENERAL HARNESS CONFIGURATION INFORMATION:
[java]
[java] Date started:
[java] Fri Sep 24 12:51:53 PDT 2010
[java] Installation directory of the JSK:
[java] com.sun.jini.jsk.home=/export/home/pats/River/trunk
[java] Installation directory of the harness:
[java] com.sun.jini.qa.home=/export/home/pats/River/trunk/qa
[java] Categories being tested:
[java] categories=No Categories
[java] -----------------------------------------
[java] ENVIRONMENT PROPERTIES:
[java]
[java] JVM information:
[java] Java HotSpot(TM) Client VM, 11.3-b02, 32 bit VM mode
[java] Sun Microsystems Inc.
[java] OS information:
[java] SunOS, 5.11, x86
[java]
[java] -----------------------------------------
[java] STARTING TO RUN THE TESTS
[java]
[java]
[java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Time is Fri Sep 24 12:51:54 PDT 2010
[java] Starting test in separate process with command:
[java] /usr/jdk/instances/jdk1.6.0/jre/bin/java
-Djava.security.policy=file:/export/home/pats/River/trunk/qa/harness/policy/defaulttest.policy
-cp
/export/home/pats/River/trunk/qa/lib/jiniharness.jar:/export/home/pats/River/trunk/qa/lib/jinitests.jar:/export/home/pats/River/trunk/lib/jsk-platform.jar:/export/home/pats/River/trunk/lib/jsk-lib.jar
-client
-Djava.ext.dirs=/usr/jdk/instances/jdk1.6.0/jre/lib/ext:/usr/jdk/packages/lib/ext:/export/home/pats/River/trunk/qa/lib-ext:/export/home/pats/River/trunk/lib-ext
-Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
-Dcom.sun.jini.jsk.home=/export/home/pats/River/trunk
-Dcom.sun.jini.qa.home=/export/home/pats/River/trunk/qa
-Dcom.sun.jini.qa.harness.harnessJar=/export/home/pats/River/trunk/qa/lib/jiniharness.jar
-Dcom.sun.jini.qa.harness.testJar=/export/home/pats/River/trunk/qa/lib/jinitests.jar
-Dcom.sun.jini.qa.harness.runjiniserver=true
-Dcom.sun.jini.qa.harness.runkitserver=true
-Djava.security.properties=file:/export/home/pats/River/trunk/qa/harness/trust/dynamic-policy.properties
-Dcom.sun.jini.qa.harness.testhosts=
-Djava.util.logging.config.file=/export/home/pats/River/trunk/qa/src/com/sun/jini/test/resources/qa1.logging
-Dcom.sun.jini.test.home=/export/home/pats/River/trunk/qa
-Dcom.sun.jini.test.port=8082
-Dcom.sun.jini.qa.harness.policies=file:/export/home/pats/River/trunk/qa/src/com/sun/jini/test/resources/jinitest.policy
-Djava.ext.dirs=/usr/jdk/instances/jdk1.6.0/jre/lib/ext:/usr/jdk/packages/lib/ext:/export/home/pats/River/trunk/qa/lib-ext:/export/home/pats/River/trunk/lib-ext
com.sun.jini.qa.harness.MasterTest
com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java]
[java] TIME: 12:51:55 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================== CALLING SETUP()
==============================
[java]
[java] MasterTest.doTest INFO:
[java] =============================== CALLING RUN()
===============================
[java]
[java] Sep 24, 2010 12:51:55 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started
[[/export/home/pats/River/trunk/qa/lib/], port 8081]
[java] Sep 24, 2010 12:51:55 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started
[[/export/home/pats/River/trunk/lib-dl/], port 8080]
[java] Sep 24, 2010 12:51:55 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started
[[/export/home/pats/River/trunk/qa/lib/], port 8082]
[java] com.sun.jini.qa.harness.TestException: Problem creating
service for net.jini.core.lookup.ServiceRegistrar; nested exception is:
[java] error during JRMP connection establishment; nested
exception is:
[java] java.net.SocketTimeoutException: Read timed out
[java] at
com.sun.jini.qa.harness.NonActivatableServiceStarterAdmin.start(Unknown
Source)
[java] at
com.sun.jini.qa.harness.AdminManager.startService(Unknown Source)
[java] at
com.sun.jini.qa.harness.AdminManager.startService(Unknown Source)
[java] at
com.sun.jini.qa.harness.AdminManager.startLookupService(Unknown Source)
[java] at
com.sun.jini.test.share.TestBase.specifyServices(Unknown Source)
[java] at
com.sun.jini.test.impl.mercury.MailboxTestBase.getPullMailbox(Unknown
Source)
[java] at
com.sun.jini.test.spec.eventmailbox.EMSRIFT_PULL.run(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.doTest(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.main(Unknown Source)
[java] Caused by: java.rmi.ConnectIOException: error during JRMP
connection establishment; nested exception is:
[java] java.net.SocketTimeoutException: Read timed out
[java] at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:286)
[java] at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
[java] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:110)
[java] at
com.sun.jini.qa.harness.NonActivatableGroupImpl$GroupImpl_Stub.startService(Unknown
Source)
[java] ... 9 more
[java] Caused by: java.net.SocketTimeoutException: Read timed out
[java] at java.net.SocketInputStream.socketRead0(Native Method)
[java] at java.net.SocketInputStream.read(SocketInputStream.java:129)
[java] at
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
[java] at
java.io.BufferedInputStream.read(BufferedInputStream.java:237)
[java] at java.io.DataInputStream.readByte(DataInputStream.java:248)
[java] at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:228)
[java] ... 12 more
[java] com.sun.jini.qa.harness.TestException: Exception has been
catched in specifyServices: Problem creating service for
net.jini.core.lookup.ServiceRegistrar; nested exception is:
[java] error during JRMP connection establishment; nested
exception is:
[java] java.net.SocketTimeoutException: Read timed out
[java] at
com.sun.jini.test.share.TestBase.specifyServices(Unknown Source)
[java] at
com.sun.jini.test.impl.mercury.MailboxTestBase.getPullMailbox(Unknown
Source)
[java] at
com.sun.jini.test.spec.eventmailbox.EMSRIFT_PULL.run(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.doTest(Unknown Source)
[java] at com.sun.jini.qa.harness.MasterTest.main(Unknown Source)
[java]
[java] TIME: 12:53:57 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================ CALLING TEARDOWN()
=============================
[java]
[java] Sep 24, 2010 12:54:57 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8082]
[java] Sep 24, 2010 12:54:57 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8082]
[java] Sep 24, 2010 12:54:57 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8080]
[java] Sep 24, 2010 12:54:57 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8080]
[java] Sep 24, 2010 12:54:57 PM com.sun.jini.tool.ClassServer
terminate
[java] INFO: ClassServer terminated [port 8081]
[java]
[java] TIME: 12:54:57 PM
[java]
[java] Test process was destroyed and returned code 1
[java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Test Failed: Test Failed:
com.sun.jini.qa.harness.TestException: Exception has been catched in
specifyServices: Problem creating service for
net.jini.core.lookup.ServiceRegistrar; nested exception is:
[java] error during JRMP connection establishment; nested
exception is:
[java] java.net.SocketTimeoutException: Read timed out
[java]
[java]
[java] -----------------------------------------
[java]
[java] SUMMARY =================================
[java]
[java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Test Failed: Test Failed:
com.sun.jini.qa.harness.TestException: Exception has been catched in
specifyServices: Problem creating service for
net.jini.core.lookup.ServiceRegistrar; nested exception is:
[java] error during JRMP connection establishment; nested
exception is:
[java] java.net.SocketTimeoutException: Read timed out
[java]
[java] -----------------------------------------
[java]
[java] # of tests started = 1
[java] # of tests completed = 1
[java] # of tests passed = 0
[java] # of tests failed = 1
[java]
[java] -----------------------------------------
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/9/25 Patricia Shanahan <pa...@acm.org>
> On 9/25/2010 2:23 AM, Sim IJskes - QCG wrote:
>
>> On 09/25/2010 11:05 AM, Patricia Shanahan wrote:
>>
>>> I needed to do a general reset before starting a new set of tests. I
>>> completely shut down (virtual power off) all my VMs and restarted the
>>> system. This happened during the first build I did after restarting the
>>> VM in question. Before the build, I had run gedit but no tests. If it is
>>> a testing framework problem, it has to be in the junit testing that is
>>> done during the build.
>>>
>>
>> The operating system is not without state, so a test might be influenced
>> by the state changes in the OS from the previous test.
>>
>> For instance when a server socket is opened, and closed, you cannot
>> immediately bind on that same server socket, unless you specify
>> SO_REUSEADDR with setsockopt(). This is because after closing the socket
>> stays in TIME_WAIT2 state for some time.
>>
>
> Across a reboot? I did a complete shut down of the VM, and restart of the
> hosting WindowsXP, between the last test and this build failure.
>
> I have had problems in the past in which killing a test left a socket tied
> up, but rebooting has always cleared it.
>
>
Yes, killing a test process could very well leave resources open.
However, the QA framework is written in such a way that tests clean up for
themselves (setup & teardown, much like JUnit tests), even if they fail or
if they cause an Exception.
When you kill a test during its execution, obviously the teardown step is
never performed...
Also .. note that activatable services leave their state written to a log
(usually in /tmp), so that they can restore themselves after a
crash/reboot/kill.
These logs are typically removed by the QA harness in the teardown step as
well.
>
>
>> So if you forget to specify SO_REUSEADDR on your server sockets, and run
>> the same test in rapid succession, it might fail.
>>
>> I did a small codereview on the TcpServerEndpoint, and no mention of the
>> ServerSocket.setReuseAddress() call, so that is a potential cause.
>>
>> Gr. Sim
>>
>>
>>
>>
>>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/9/25 Sim IJskes - QCG <si...@qcg.nl>
> On 09/25/2010 01:59 PM, Patricia Shanahan wrote:
>
>> On 9/25/2010 3:02 AM, Sim IJskes - QCG wrote:
>>
>>> On 09/25/2010 11:45 AM, Jonathan Costers wrote:
>>>
>>>> as you can derive from this snippet:
>>>>
>>>
>>> Thanks, but are we debugging the VM or the part we have influence on.
>>> Did we cause a sequence error in the build process or not? Is this
>>> caused by assuming some kind of state, without initializing?
>>>
>>> Gr. Sim
>>>
>>>
>> Or it could even be both a build script problem and a tools problem.
>>
>
>
> We
>> could have a problem in the build that creates an unusual situation that
>> is handled incorrectly, causing a crash rather than an error report.
>>
>
> My intuition tells me this is the case. A VM should not crash. It does, and
> it look very much like a problem i had, where i had 2 builds overlap, and
> the second build, cleaned away the jars the first build used. I also had
> lookalike problems when i used a class for the first time in a
> shutdownhandler (Runtime.addShutdownHook).
>
>
Nothing like this is happening during the River build, to my knowledge.
Everything is done sequentially ...
I would expect the VM to throw some kind of Error, but thats obviously not
> the case.
>
> The number of threads in the threaddump is very small, so either its near
> startup or shutdown.
>
> The unices i used, had a tendency to start all daemons first and then allow
> user login, but nowadays the gui is started while the daemons are starting,
> (If i could find the time, i would create a singleuser unix instance without
> any daemons, to run as a test slave for hudson).
>
> Gr. Sim
>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 02:40 PM, Sim IJskes - QCG wrote:
> The number of threads in the threaddump is very small, so either its
> near startup or shutdown.
Forget this one. If i would build a compiler, it could very well be a
single-thread one.
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 01:59 PM, Patricia Shanahan wrote:
> On 9/25/2010 3:02 AM, Sim IJskes - QCG wrote:
>> On 09/25/2010 11:45 AM, Jonathan Costers wrote:
>>> as you can derive from this snippet:
>>
>> Thanks, but are we debugging the VM or the part we have influence on.
>> Did we cause a sequence error in the build process or not? Is this
>> caused by assuming some kind of state, without initializing?
>>
>> Gr. Sim
>>
>
> Or it could even be both a build script problem and a tools problem.
> We
> could have a problem in the build that creates an unusual situation that
> is handled incorrectly, causing a crash rather than an error report.
My intuition tells me this is the case. A VM should not crash. It does,
and it look very much like a problem i had, where i had 2 builds
overlap, and the second build, cleaned away the jars the first build
used. I also had lookalike problems when i used a class for the first
time in a shutdownhandler (Runtime.addShutdownHook).
I would expect the VM to throw some kind of Error, but thats obviously
not the case.
The number of threads in the threaddump is very small, so either its
near startup or shutdown.
The unices i used, had a tendency to start all daemons first and then
allow user login, but nowadays the gui is started while the daemons are
starting, (If i could find the time, i would create a singleuser unix
instance without any daemons, to run as a test slave for hudson).
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/25/2010 3:02 AM, Sim IJskes - QCG wrote:
> On 09/25/2010 11:45 AM, Jonathan Costers wrote:
>> as you can derive from this snippet:
>
> Thanks, but are we debugging the VM or the part we have influence on.
> Did we cause a sequence error in the build process or not? Is this
> caused by assuming some kind of state, without initializing?
>
> Gr. Sim
>
Or it could even be both a build script problem and a tools problem. We
could have a problem in the build that creates an unusual situation that
is handled incorrectly, causing a crash rather than an error report.
After looking at the behavior of my VMs, I'm wondering if this is a
first-build-after-boot problem.
Patricia
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 03:15 PM, Jonathan Costers wrote:
> Not sure if I follow you ... Debug the VM?
> The crash report clearly shows what is causing the VM to crash, or am I
> missing something? :-)
> As far as I know, no sequence error ... the build works fine 95% of the
> time.
> And no, no assumptions abt state either.
> I'm suspecting something in the JarWrapper code is causing this to happen in
> some cicumstances.
The crashing VM does not prove either a correct or incorrect test
result. So it's a waste of time.
When something works not 100% or 0% of the time, clearly its result
depends on external factors.
If i would have known about a sequence error, i would have told you. But
you cannot exclude it. Tasks overlapping, daemons binding sockets you
want to use, scheduling delays, etc.
The only thing we can do here is to run on a daemonless system, with as
little network (outside) interaction as possible.
But then, what does this tell us about robustness in a heterogeneous
environment.
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Gregg Wonderly <gr...@wonderly.org>.
I can trigger these kinds of crashes, usually, by just overwriting a jar file
that is referenced by a running JVM, which has not loaded some classes in that
jar. If I then trigger some action to load an unloaded class, it appears that
an in memory index is not correctly tracked against the change on disk, and
things get ugly.
Gregg Wonderly
On 9/25/2010 8:50 AM, Jonathan Costers wrote:
> 2010/9/25 Patricia Shanahan<pa...@acm.org>
>
>> On 9/25/2010 6:15 AM, Jonathan Costers wrote:
>>
>>> Not sure if I follow you ... Debug the VM?
>>> The crash report clearly shows what is causing the VM to crash, or am I
>>> missing something? :-)
>>>
>>
>> I think what you may be missing is the wide range of different backgrounds
>> of River developers. What is immediately clear to you is not necessarily
>> clear to me, probably because you know some things, or have experience, that
>> I lack.
>>
>> Please state your conclusions from the crash report.
>>
>> My apologies ..
> I thought the snippet I pasted in my previous email explained, I'm sorry.
> My conclusion is that the VM crash for which you posted the report is
> happening during execution of the JarWrapper class, which is used during the
> build, for creating the tools wrapper jars (classdep.jar,
> preferredlistgen.jar, etc.).
>
> *C [libc.so.6+0x1106ef]
> C [libzip.so+0x4578] ZIP_GetEntry+0xc8
> C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
> J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
> J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
> J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
> j
> java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
> j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
> j
> java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
> j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
>
> ------
> j com.sun.jini.tool.JarWrapper.
> getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
> j
> com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
> j com.sun.jini.tool.JarWrapper.wrap()V+19
> j
> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
> j
> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
> j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379*
>
> ------
>
> The reason why it is crashing, I am not sure yet.
> But it may be related to the way the Ant build is calling these classes.
> I'm doing some testing right now to be sure
>
>
>> As far as I know, no sequence error ... the build works fine 95% of the
>>> time.
>>> And no, no assumptions abt state either.
>>> I'm suspecting something in the JarWrapper code is causing this to happen
>>> in
>>> some cicumstances.
>>>
>>
>>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/27/2010 12:40 PM, Jonathan Costers wrote:
> I think I identified the cause of the issue:
>
> PreferredListgen, ClassDep and JarWrapper classes are executed during the
> build, but the<java> task does not have the attribute "fork" set to "true".
> The Ant documentation for<java> mentions that sometimes strange things can
> happen without using fork=true ... So they recommend setting it if that
> happens.
> I tried doing that over the weekend, and let the build run for 200
> consecutive times, using a bash script with a for loop.
> I didn't see a single VM crash anymore.
Ah. Nice one! fork=true runs in separate VM, fork=false in the same as
ant. Thats a lot of state to carry with you! ;-)
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
Excellent! I'll look forward to build scripts with that fixed. I got
tired of failed builds during my recent debug activity - with logging
suppressing the problem I was dependent on editing in System.err.printf
calls and rebuilding.
Patricia
On 9/27/2010 3:40 AM, Jonathan Costers wrote:
> I think I identified the cause of the issue:
>
> PreferredListgen, ClassDep and JarWrapper classes are executed during the
> build, but the<java> task does not have the attribute "fork" set to "true".
> The Ant documentation for<java> mentions that sometimes strange things can
> happen without using fork=true ... So they recommend setting it if that
> happens.
> I tried doing that over the weekend, and let the build run for 200
> consecutive times, using a bash script with a for loop.
> I didn't see a single VM crash anymore.
>
>
> 2010/9/25 Jonathan Costers<jo...@googlemail.com>
>
>>
>>
>> 2010/9/25 Patricia Shanahan<pa...@acm.org>
>>
>>> On 9/25/2010 6:15 AM, Jonathan Costers wrote:
>>>
>>> Not sure if I follow you ... Debug the VM?
>>>> The crash report clearly shows what is causing the VM to crash, or am I
>>>> missing something? :-)
>>>>
>>>
>>> I think what you may be missing is the wide range of different backgrounds
>>> of River developers. What is immediately clear to you is not necessarily
>>> clear to me, probably because you know some things, or have experience, that
>>> I lack.
>>>
>>> Please state your conclusions from the crash report.
>>>
>>> My apologies ..
>> I thought the snippet I pasted in my previous email explained, I'm sorry.
>> My conclusion is that the VM crash for which you posted the report is
>> happening during execution of the JarWrapper class, which is used during the
>> build, for creating the tools wrapper jars (classdep.jar,
>> preferredlistgen.jar, etc.).
>>
>> *
>> C [libc.so.6+0x1106ef]
>> C [libzip.so+0x4578] ZIP_GetEntry+0xc8
>> C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
>>
>> J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
>> J
>> java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
>> J
>> java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
>> j
>> java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
>> j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
>> j
>> java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
>> j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
>>
>> ------
>> j com.sun.jini.tool.JarWrapper.
>> getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
>> j
>> com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
>> j com.sun.jini.tool.JarWrapper.wrap()V+19
>> j
>> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
>> j
>> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
>> j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379
>> *
>>
>> ------
>>
>> The reason why it is crashing, I am not sure yet.
>> But it may be related to the way the Ant build is calling these classes.
>> I'm doing some testing right now to be sure
>>
>>
>>> As far as I know, no sequence error ... the build works fine 95% of the
>>>> time.
>>>> And no, no assumptions abt state either.
>>>> I'm suspecting something in the JarWrapper code is causing this to happen
>>>> in
>>>> some cicumstances.
>>>>
>>>
>>>
>>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
I think I identified the cause of the issue:
PreferredListgen, ClassDep and JarWrapper classes are executed during the
build, but the <java> task does not have the attribute "fork" set to "true".
The Ant documentation for <java> mentions that sometimes strange things can
happen without using fork=true ... So they recommend setting it if that
happens.
I tried doing that over the weekend, and let the build run for 200
consecutive times, using a bash script with a for loop.
I didn't see a single VM crash anymore.
2010/9/25 Jonathan Costers <jo...@googlemail.com>
>
>
> 2010/9/25 Patricia Shanahan <pa...@acm.org>
>
>> On 9/25/2010 6:15 AM, Jonathan Costers wrote:
>>
>> Not sure if I follow you ... Debug the VM?
>>> The crash report clearly shows what is causing the VM to crash, or am I
>>> missing something? :-)
>>>
>>
>> I think what you may be missing is the wide range of different backgrounds
>> of River developers. What is immediately clear to you is not necessarily
>> clear to me, probably because you know some things, or have experience, that
>> I lack.
>>
>> Please state your conclusions from the crash report.
>>
>> My apologies ..
> I thought the snippet I pasted in my previous email explained, I'm sorry.
> My conclusion is that the VM crash for which you posted the report is
> happening during execution of the JarWrapper class, which is used during the
> build, for creating the tools wrapper jars (classdep.jar,
> preferredlistgen.jar, etc.).
>
> *
> C [libc.so.6+0x1106ef]
> C [libzip.so+0x4578] ZIP_GetEntry+0xc8
> C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
>
> J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
> J
> java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
> J
> java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
> j
> java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
> j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
> j
> java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
> j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
>
> ------
> j com.sun.jini.tool.JarWrapper.
> getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
> j
> com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
> j com.sun.jini.tool.JarWrapper.wrap()V+19
> j
> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
> j
> com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
> j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379
> *
>
> ------
>
> The reason why it is crashing, I am not sure yet.
> But it may be related to the way the Ant build is calling these classes.
> I'm doing some testing right now to be sure
>
>
>> As far as I know, no sequence error ... the build works fine 95% of the
>>> time.
>>> And no, no assumptions abt state either.
>>> I'm suspecting something in the JarWrapper code is causing this to happen
>>> in
>>> some cicumstances.
>>>
>>
>>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/9/25 Patricia Shanahan <pa...@acm.org>
> On 9/25/2010 6:15 AM, Jonathan Costers wrote:
>
>> Not sure if I follow you ... Debug the VM?
>> The crash report clearly shows what is causing the VM to crash, or am I
>> missing something? :-)
>>
>
> I think what you may be missing is the wide range of different backgrounds
> of River developers. What is immediately clear to you is not necessarily
> clear to me, probably because you know some things, or have experience, that
> I lack.
>
> Please state your conclusions from the crash report.
>
> My apologies ..
I thought the snippet I pasted in my previous email explained, I'm sorry.
My conclusion is that the VM crash for which you posted the report is
happening during execution of the JarWrapper class, which is used during the
build, for creating the tools wrapper jars (classdep.jar,
preferredlistgen.jar, etc.).
*C [libc.so.6+0x1106ef]
C [libzip.so+0x4578] ZIP_GetEntry+0xc8
C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
j
java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
------
j com.sun.jini.tool.JarWrapper.
getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
j
com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
j com.sun.jini.tool.JarWrapper.wrap()V+19
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379*
------
The reason why it is crashing, I am not sure yet.
But it may be related to the way the Ant build is calling these classes.
I'm doing some testing right now to be sure
> As far as I know, no sequence error ... the build works fine 95% of the
>> time.
>> And no, no assumptions abt state either.
>> I'm suspecting something in the JarWrapper code is causing this to happen
>> in
>> some cicumstances.
>>
>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/25/2010 6:15 AM, Jonathan Costers wrote:
> Not sure if I follow you ... Debug the VM?
> The crash report clearly shows what is causing the VM to crash, or am I
> missing something? :-)
I think what you may be missing is the wide range of different
backgrounds of River developers. What is immediately clear to you is not
necessarily clear to me, probably because you know some things, or have
experience, that I lack.
Please state your conclusions from the crash report.
> As far as I know, no sequence error ... the build works fine 95% of the
> time.
> And no, no assumptions abt state either.
> I'm suspecting something in the JarWrapper code is causing this to happen in
> some cicumstances.
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
Not sure if I follow you ... Debug the VM?
The crash report clearly shows what is causing the VM to crash, or am I
missing something? :-)
As far as I know, no sequence error ... the build works fine 95% of the
time.
And no, no assumptions abt state either.
I'm suspecting something in the JarWrapper code is causing this to happen in
some cicumstances.
2010/9/25 Sim IJskes - QCG <si...@qcg.nl>
> On 09/25/2010 11:45 AM, Jonathan Costers wrote:
>
>> as you can derive from this snippet:
>>
>
> Thanks, but are we debugging the VM or the part we have influence on. Did
> we cause a sequence error in the build process or not? Is this caused by
> assuming some kind of state, without initializing?
>
> Gr. Sim
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 11:45 AM, Jonathan Costers wrote:
> as you can derive from this snippet:
Thanks, but are we debugging the VM or the part we have influence on.
Did we cause a sequence error in the build process or not? Is this
caused by assuming some kind of state, without initializing?
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Jonathan Costers <jo...@googlemail.com>.
as you can derive from this snippet:
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
j
java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
*j
com.sun.jini.tool.JarWrapper.getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
j
com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
j com.sun.jini.tool.JarWrapper.wrap()V+19
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379*
v ~StubRoutines::call_stub
j
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j org.apache.tools.ant.taskdefs.ExecuteJava.run()V+35
j
org.apache.tools.ant.taskdefs.ExecuteJava.execute(Lorg/apache/tools/ant/Project;)V+265
j
org.apache.tools.ant.taskdefs.Java.run(Lorg/apache/tools/ant/types/CommandlineJava;)V+60
j
org.apache.tools.ant.taskdefs.Java.executeJava(Lorg/apache/tools/ant/types/CommandlineJava;)I+35
j org.apache.tools.ant.taskdefs.Java.executeJava()I+5
j org.apache.tools.ant.taskdefs.Java.execute()V+17
j org.apache.tools.ant.UnknownElement.execute()V+58
The crash happens during execution of JarWrapper (creating the tools wrapper
JARs during the build), in this case.
I've seen them happening durin PreferredListgen execution as well.
2010/9/25 Sim IJskes - QCG <si...@qcg.nl>
> On 09/25/2010 11:28 AM, Patricia Shanahan wrote:
>
> Across a reboot? I did a complete shut down of the VM, and restart of
>> the hosting WindowsXP, between the last test and this build failure.
>>
>
> No.
>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 11:28 AM, Patricia Shanahan wrote:
> Across a reboot? I did a complete shut down of the VM, and restart of
> the hosting WindowsXP, between the last test and this build failure.
No.
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/25/2010 2:42 AM, Sim IJskes - QCG wrote:
> On 09/25/2010 11:28 AM, Patricia Shanahan wrote:
>
>> Across a reboot? I did a complete shut down of the VM, and restart of
>> the hosting WindowsXP, between the last test and this build failure.
>
> So, what your are saying is, it failed before ANY test was run?
No tests ran between virtually powering up the VM, booting Ubuntu, and
the start of the build. Some junit tests had run from the build before
the JVM crash.
Patricia
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 11:28 AM, Patricia Shanahan wrote:
> Across a reboot? I did a complete shut down of the VM, and restart of
> the hosting WindowsXP, between the last test and this build failure.
So, what your are saying is, it failed before ANY test was run?
> I have had problems in the past in which killing a test left a socket
> tied up, but rebooting has always cleared it.
Exactly my point.
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/25/2010 2:23 AM, Sim IJskes - QCG wrote:
> On 09/25/2010 11:05 AM, Patricia Shanahan wrote:
>> I needed to do a general reset before starting a new set of tests. I
>> completely shut down (virtual power off) all my VMs and restarted the
>> system. This happened during the first build I did after restarting the
>> VM in question. Before the build, I had run gedit but no tests. If it is
>> a testing framework problem, it has to be in the junit testing that is
>> done during the build.
>
> The operating system is not without state, so a test might be influenced
> by the state changes in the OS from the previous test.
>
> For instance when a server socket is opened, and closed, you cannot
> immediately bind on that same server socket, unless you specify
> SO_REUSEADDR with setsockopt(). This is because after closing the socket
> stays in TIME_WAIT2 state for some time.
Across a reboot? I did a complete shut down of the VM, and restart of
the hosting WindowsXP, between the last test and this build failure.
I have had problems in the past in which killing a test left a socket
tied up, but rebooting has always cleared it.
>
> So if you forget to specify SO_REUSEADDR on your server sockets, and run
> the same test in rapid succession, it might fail.
>
> I did a small codereview on the TcpServerEndpoint, and no mention of the
> ServerSocket.setReuseAddress() call, so that is a potential cause.
>
> Gr. Sim
>
>
>
>
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 11:05 AM, Patricia Shanahan wrote:
> I needed to do a general reset before starting a new set of tests. I
> completely shut down (virtual power off) all my VMs and restarted the
> system. This happened during the first build I did after restarting the
> VM in question. Before the build, I had run gedit but no tests. If it is
> a testing framework problem, it has to be in the junit testing that is
> done during the build.
The operating system is not without state, so a test might be influenced
by the state changes in the OS from the previous test.
For instance when a server socket is opened, and closed, you cannot
immediately bind on that same server socket, unless you specify
SO_REUSEADDR with setsockopt(). This is because after closing the socket
stays in TIME_WAIT2 state for some time.
So if you forget to specify SO_REUSEADDR on your server sockets, and run
the same test in rapid succession, it might fail.
I did a small codereview on the TcpServerEndpoint, and no mention of the
ServerSocket.setReuseAddress() call, so that is a potential cause.
Gr. Sim
Re: Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/25/2010 1:53 AM, Sim IJskes - QCG wrote:
> On 09/25/2010 10:44 AM, Patricia Shanahan wrote:
>> On 9/23/2010 7:09 AM, Jonathan Costers wrote:
>>> I have been planning to log a problem ticket at Oracle for these JVM
>>> crashes. So, if anyone comes across them, please post the
>>> hs_err_pidxxxx.log
>>> file that is outputed with the JVM crashes.
>>
>>
>> This one was from OpenJDK - do you want to file separate bug reports for
>> each, or just file the Oracle one? As far as I can tell, both have the
>> problem, so it presumably predates the split.
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
>> J
>> java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
>>
>
> I've seen many of these errors, in other projects. They were all caused
> by another process removing the jar files. I've also seen these errors
> during classloading in onexit handlers.
>
> Might there be a problem in the testing framework, where it cannot
> accurately kill a child vm, or cannot accurately wait until the child vm
> process is completely killed?
I like the framework theory because it explains the problem appearing
without picking up a new JDK and applying to both the Sun JDK and OpenJDK.
I needed to do a general reset before starting a new set of tests. I
completely shut down (virtual power off) all my VMs and restarted the
system. This happened during the first build I did after restarting the
VM in question. Before the build, I had run gedit but no tests. If it is
a testing framework problem, it has to be in the junit testing that is
done during the build.
Could it be in the build framework rather than the testing framework?
Patricia
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 10:44 AM, Patricia Shanahan wrote:
> On 9/23/2010 7:09 AM, Jonathan Costers wrote:
>> I have been planning to log a problem ticket at Oracle for these JVM
>> crashes. So, if anyone comes across them, please post the
>> hs_err_pidxxxx.log
>> file that is outputed with the JVM crashes.
>
>
> This one was from OpenJDK - do you want to file separate bug reports for
> each, or just file the Oracle one? As far as I can tell, both have the
> problem, so it presumably predates the split.
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
> J
> java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
I've seen many of these errors, in other projects. They were all caused
by another process removing the jar files. I've also seen these errors
during classloading in onexit handlers.
Might there be a problem in the testing framework, where it cannot
accurately kill a child vm, or cannot accurately wait until the child vm
process is completely killed?
Gr. SIm
Re: Build crashes (Was: Re: Request for testing help)
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 09/25/2010 10:44 AM, Patricia Shanahan wrote:
> Dynamic libraries:
> /usr/share/java/gnome-java-bridge.jar
> /usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar
As the process should be pretty headless, could you make a run without
these jars? (assuming pulse-java.jar is an api to the pulseaudio daemon).
Gr. Sim
Build crashes (Was: Re: Request for testing help)
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/23/2010 7:09 AM, Jonathan Costers wrote:
> I have been planning to log a problem ticket at Oracle for these JVM
> crashes. So, if anyone comes across them, please post the hs_err_pidxxxx.log
> file that is outputed with the JVM crashes.
This one was from OpenJDK - do you want to file separate bug reports for
each, or just file the Oracle one? As far as I can tell, both have the
problem, so it presumably predates the split.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x007c56ef, pid=1641, tid=3077688176
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing linux-x86 )
# Derivative: IcedTea6 1.8.1
# Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
# Problematic frame:
# C [libc.so.6+0x1106ef]
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x09c76400): JavaThread "main" [_thread_in_native,
id=1644, stack(0xb76cc000,0xb771d000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),
si_addr=0xb4c7a000
Registers:
EAX=0xb4c78940, EBX=0x007ef5b0, ECX=0x000076a9, EDX=0xb4b5cc00
ESP=0xb771a9e4, EBP=0xb771aa48, ESI=0xb4c7616a, EDI=0x000016a0
EIP=0x007c56ef, CR2=0xb4c7a000, EFLAGS=0x00010206
Top of Stack: (sp=0xb771a9e4)
0xb771a9e4: b4b6f2a0 00167ff4 0016439b b4b5cbfa
0xb771a9f4: b4c78941 00008d8f 01194ff4 0000004a
0xb771aa04: 0a092858 b771aa28 00f92a50 0a0928c0
0xb771aa14: 00000000 b771aa88 00f92a2c 8d8f321d
0xb771aa24: b4b6f2a0 00008d8f 000027a9 0a0928c0
0xb771aa34: 09c76400 001641ad 00167ff4 09d11b64
0xb771aa44: 0a092858 b771aa88 00164578 00000000
0xb771aa54: b771aada 09c76400 00000000 00000000
Instructions: (pc=0x007c56ef)
0x007c56df: 0f 7f 5c 3a f0 7c 30 66 0f 6f 54 38 10 83 e9 20
0x007c56ef: 66 0f 6f 5c 38 20 66 0f 6f cb 66 0f 3a 0f da 07
Stack: [0xb76cc000,0xb771d000], sp=0xb771a9e4, free space=13ab771a384k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libc.so.6+0x1106ef]
C [libzip.so+0x4578] ZIP_GetEntry+0xc8
C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J
java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J
java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
j
java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
j
com.sun.jini.tool.JarWrapper.getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
j
com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
j com.sun.jini.tool.JarWrapper.wrap()V+19
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379
v ~StubRoutines::call_stub
V [libjvm.so+0x1e5b75]
V [libjvm.so+0x2d67d9]
V [libjvm.so+0x1e4a6f]
V [libjvm.so+0x31029c]
V [libjvm.so+0x310f9e]
V [libjvm.so+0x23a411]
C [libjava.so+0x15f92]
Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x32
j
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j org.apache.tools.ant.taskdefs.ExecuteJava.run()V+35
j
org.apache.tools.ant.taskdefs.ExecuteJava.execute(Lorg/apache/tools/ant/Project;)V+265
j
org.apache.tools.ant.taskdefs.Java.run(Lorg/apache/tools/ant/types/CommandlineJava;)V+60
j
org.apache.tools.ant.taskdefs.Java.executeJava(Lorg/apache/tools/ant/types/CommandlineJava;)I+35
j org.apache.tools.ant.taskdefs.Java.executeJava()I+5
j org.apache.tools.ant.taskdefs.Java.execute()V+17
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.taskdefs.Sequential.execute()V+28
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.taskdefs.MacroInstance.execute()V+486
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.Target.execute()V+53
j org.apache.tools.ant.Target.performTasks()V+11
j
org.apache.tools.ant.Project.executeSortedTargets(Ljava/util/Vector;)V+145
j org.apache.tools.ant.Project.executeTarget(Ljava/lang/String;)V+27
j
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(Lorg/apache/tools/ant/Project;[Ljava/lang/String;)V+17
j org.apache.tools.ant.Project.executeTargets(Ljava/util/Vector;)V+22
j org.apache.tools.ant.Main.runBuild(Ljava/lang/ClassLoader;)V+414
j
org.apache.tools.ant.Main.startAnt([Ljava/lang/String;Ljava/util/Properties;Ljava/lang/ClassLoader;)V+87
j org.apache.tools.ant.launch.Launcher.run([Ljava/lang/String;)I+601
j org.apache.tools.ant.launch.Launcher.main([Ljava/lang/String;)V+10
v ~StubRoutines::call_stub
V [libjvm.so+0x1e5b75]
V [libjvm.so+0x2d67d9]
V [libjvm.so+0x1e4a6f]
V [libjvm.so+0x1ef5cc]
V [libjvm.so+0x20934d]
C [java+0x321d] JavaMain+0xd4d
C [libpthread.so.0+0x596e]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J
java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J
java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
j
java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
j
com.sun.jini.tool.JarWrapper.getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
j
com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
j com.sun.jini.tool.JarWrapper.wrap()V+19
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379
v ~StubRoutines::call_stub
j
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
j
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j org.apache.tools.ant.taskdefs.ExecuteJava.run()V+35
j
org.apache.tools.ant.taskdefs.ExecuteJava.execute(Lorg/apache/tools/ant/Project;)V+265
j
org.apache.tools.ant.taskdefs.Java.run(Lorg/apache/tools/ant/types/CommandlineJava;)V+60
j
org.apache.tools.ant.taskdefs.Java.executeJava(Lorg/apache/tools/ant/types/CommandlineJava;)I+35
j org.apache.tools.ant.taskdefs.Java.executeJava()I+5
j org.apache.tools.ant.taskdefs.Java.execute()V+17
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.taskdefs.Sequential.execute()V+28
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.taskdefs.MacroInstance.execute()V+486
j org.apache.tools.ant.UnknownElement.execute()V+58
j
sun.reflect.GeneratedMethodAccessor1.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+36
J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
j
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161
j
org.apache.tools.ant.dispatch.DispatchUtils.execute(Ljava/lang/Object;)V+518
j org.apache.tools.ant.Task.perform()V+22
j org.apache.tools.ant.Target.execute()V+53
j org.apache.tools.ant.Target.performTasks()V+11
j
org.apache.tools.ant.Project.executeSortedTargets(Ljava/util/Vector;)V+145
j org.apache.tools.ant.Project.executeTarget(Ljava/lang/String;)V+27
j
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(Lorg/apache/tools/ant/Project;[Ljava/lang/String;)V+17
j org.apache.tools.ant.Project.executeTargets(Ljava/util/Vector;)V+22
j org.apache.tools.ant.Main.runBuild(Ljava/lang/ClassLoader;)V+414
j
org.apache.tools.ant.Main.startAnt([Ljava/lang/String;Ljava/util/Properties;Ljava/lang/ClassLoader;)V+87
j org.apache.tools.ant.launch.Launcher.run([Ljava/lang/String;)I+601
j org.apache.tools.ant.launch.Launcher.main([Ljava/lang/String;)V+10
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0xb4f00800 JavaThread "Low Memory Detector" daemon [_thread_blocked,
id=1650, stack(0xb4eaf000,0xb4f00000)]
0x09caf000 JavaThread "CompilerThread0" daemon [_thread_blocked,
id=1649, stack(0xb504e000,0xb50cf000)]
0x09cad400 JavaThread "Signal Dispatcher" daemon [_thread_blocked,
id=1648, stack(0xb50cf000,0xb5120000)]
0x09ca4c00 JavaThread "Finalizer" daemon [_thread_blocked, id=1647,
stack(0xb5166000,0xb51b7000)]
0x09ca3000 JavaThread "Reference Handler" daemon [_thread_blocked,
id=1646, stack(0xb51b7000,0xb5208000)]
=>0x09c76400 JavaThread "main" [_thread_in_native, id=1644,
stack(0xb76cc000,0xb771d000)]
Other Threads:
0x09ca1800 VMThread [stack: 0xb5208000,0xb5289000] [id=1645]
0xb4f03000 WatcherThread [stack: 0xb4e2e000,0xb4eaf000] [id=1651]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 7552K, used 4709K [0x70230000, 0x70a60000,
0x7a980000)
eden space 6720K, 69% used [0x70230000, 0x706bf238, 0x708c0000)
from space 832K, 4% used [0x70990000, 0x7099a470, 0x70a60000)
to space 832K, 0% used [0x708c0000, 0x708c0000, 0x70990000)
tenured generation total 16652K, used 10540K [0x7a980000,
0x7b9c3000, 0x8f830000)
the space 16652K, 63% used [0x7a980000, 0x7b3cb108, 0x7b3cb200,
0x7b9c3000)
compacting perm gen total 12288K, used 8681K [0x8f830000, 0x90430000,
0x93830000)
the space 12288K, 70% used [0x8f830000, 0x900aa7e8, 0x900aa800,
0x90430000)
ro space 10240K, 72% used [0x93830000, 0x93f7a798, 0x93f7a800,
0x94230000)
rw space 12288K, 60% used [0x94230000, 0x9496b2a8, 0x9496b400,
0x94e30000)
Dynamic libraries:
00110000-00134000 r-xp 00000000 08:01 525263
/lib/tls/i686/cmov/libm-2.11.1.so
00134000-00135000 r--p 00023000 08:01 525263
/lib/tls/i686/cmov/libm-2.11.1.so
00135000-00136000 rw-p 00024000 08:01 525263
/lib/tls/i686/cmov/libm-2.11.1.so
00136000-0013d000 r-xp 00000000 08:01 525363
/lib/tls/i686/cmov/librt-2.11.1.so
0013d000-0013e000 r--p 00006000 08:01 525363
/lib/tls/i686/cmov/librt-2.11.1.so
0013e000-0013f000 rw-p 00007000 08:01 525363
/lib/tls/i686/cmov/librt-2.11.1.so
0013f000-00152000 r-xp 00000000 08:01 525353
/lib/tls/i686/cmov/libnsl-2.11.1.so
00152000-00153000 r--p 00012000 08:01 525353
/lib/tls/i686/cmov/libnsl-2.11.1.so
00153000-00154000 rw-p 00013000 08:01 525353
/lib/tls/i686/cmov/libnsl-2.11.1.so
00154000-00156000 rw-p 00000000 00:00 0
00156000-0015e000 r-xp 00000000 08:01 525358
/lib/tls/i686/cmov/libnss_nis-2.11.1.so
0015e000-0015f000 r--p 00007000 08:01 525358
/lib/tls/i686/cmov/libnss_nis-2.11.1.so
0015f000-00160000 rw-p 00008000 08:01 525358
/lib/tls/i686/cmov/libnss_nis-2.11.1.so
00160000-00167000 r-xp 00000000 08:01 530822
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libzip.so
00167000-00168000 r--p 00006000 08:01 530822
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libzip.so
00168000-00169000 rw-p 00007000 08:01 530822
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libzip.so
00169000-00179000 r-xp 00000000 08:01 525362
/lib/tls/i686/cmov/libresolv-2.11.1.so
00179000-0017a000 r--p 00010000 08:01 525362
/lib/tls/i686/cmov/libresolv-2.11.1.so
0017a000-0017b000 rw-p 00011000 08:01 525362
/lib/tls/i686/cmov/libresolv-2.11.1.so
0017b000-0017d000 rw-p 00000000 00:00 0
002c8000-002e3000 r-xp 00000000 08:01 525329 /lib/ld-2.11.1.so
002e3000-002e4000 r--p 0001a000 08:01 525329 /lib/ld-2.11.1.so
002e4000-002e5000 rw-p 0001b000 08:01 525329 /lib/ld-2.11.1.so
002e9000-002fc000 r-xp 00000000 08:01 521422 /lib/libz.so.1.2.3.3
002fc000-002fd000 r--p 00012000 08:01 521422 /lib/libz.so.1.2.3.3
002fd000-002fe000 rw-p 00013000 08:01 521422 /lib/libz.so.1.2.3.3
00367000-00371000 r-xp 00000000 08:01 525356
/lib/tls/i686/cmov/libnss_files-2.11.1.so
00371000-00372000 r--p 00009000 08:01 525356
/lib/tls/i686/cmov/libnss_files-2.11.1.so
00372000-00373000 rw-p 0000a000 08:01 525356
/lib/tls/i686/cmov/libnss_files-2.11.1.so
0040b000-0040c000 r-xp 00000000 00:00 0 [vdso]
00512000-0051e000 r-xp 00000000 08:01 530821
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libverify.so
0051e000-0051f000 r--p 0000b000 08:01 530821
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libverify.so
0051f000-00520000 rw-p 0000c000 08:01 530821
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libverify.so
0062a000-00630000 r-xp 00000000 08:01 525354
/lib/tls/i686/cmov/libnss_compat-2.11.1.so
00630000-00631000 r--p 00006000 08:01 525354
/lib/tls/i686/cmov/libnss_compat-2.11.1.so
00631000-00632000 rw-p 00007000 08:01 525354
/lib/tls/i686/cmov/libnss_compat-2.11.1.so
00666000-0068a000 r-xp 00000000 08:01 530804
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libjava.so
0068a000-0068b000 r--p 00023000 08:01 530804
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libjava.so
0068b000-0068d000 rw-p 00024000 08:01 530804
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libjava.so
00695000-006aa000 r-xp 00000000 08:01 525361
/lib/tls/i686/cmov/libpthread-2.11.1.so
006aa000-006ab000 r--p 00014000 08:01 525361
/lib/tls/i686/cmov/libpthread-2.11.1.so
006ab000-006ac000 rw-p 00015000 08:01 525361
/lib/tls/i686/cmov/libpthread-2.11.1.so
006ac000-006ae000 rw-p 00000000 00:00 0
006b5000-00808000 r-xp 00000000 08:01 521398
/lib/tls/i686/cmov/libc-2.11.1.so
00808000-00809000 ---p 00153000 08:01 521398
/lib/tls/i686/cmov/libc-2.11.1.so
00809000-0080b000 r--p 00153000 08:01 521398
/lib/tls/i686/cmov/libc-2.11.1.so
0080b000-0080c000 rw-p 00155000 08:01 521398
/lib/tls/i686/cmov/libc-2.11.1.so
0080c000-0080f000 rw-p 00000000 00:00 0
0090f000-00913000 r-xp 00000000 08:01 525355
/lib/tls/i686/cmov/libnss_dns-2.11.1.so
00913000-00914000 r--p 00004000 08:01 525355
/lib/tls/i686/cmov/libnss_dns-2.11.1.so
00914000-00915000 rw-p 00005000 08:01 525355
/lib/tls/i686/cmov/libnss_dns-2.11.1.so
0096e000-00975000 r-xp 00000000 08:01 530823
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/native_threads/libhpi.so
00975000-00976000 r--p 00006000 08:01 530823
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/native_threads/libhpi.so
00976000-00977000 rw-p 00007000 08:01 530823
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/native_threads/libhpi.so
00a52000-00a54000 r-xp 00000000 08:01 521345
/lib/libnss_mdns4_minimal.so.2
00a54000-00a55000 r--p 00001000 08:01 521345
/lib/libnss_mdns4_minimal.so.2
00a55000-00a56000 rw-p 00002000 08:01 521345
/lib/libnss_mdns4_minimal.so.2
00ac7000-00ac9000 r-xp 00000000 08:01 525262
/lib/tls/i686/cmov/libdl-2.11.1.so
00ac9000-00aca000 r--p 00001000 08:01 525262
/lib/tls/i686/cmov/libdl-2.11.1.so
00aca000-00acb000 rw-p 00002000 08:01 525262
/lib/tls/i686/cmov/libdl-2.11.1.so
00b07000-00b1b000 r-xp 00000000 08:01 530815
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libnet.so
00b1b000-00b1c000 r--p 00013000 08:01 530815
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libnet.so
00b1c000-00b1d000 rw-p 00014000 08:01 530815
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/libnet.so
00d66000-00d69000 r-xp 00000000 08:01 530788
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/libjli.so
00d69000-00d6a000 r--p 00003000 08:01 530788
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/libjli.so
00d6a000-00d6b000 rw-p 00004000 08:01 530788
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/jli/libjli.so
00d6b000-0117e000 r-xp 00000000 08:01 530785
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
0117e000-01195000 r--p 00412000 08:01 530785
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
01195000-011a2000 rw-p 00429000 08:01 530785
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so
011a2000-015be000 rw-p 00000000 00:00 0
08048000-08051000 r-xp 00000000 08:01 530845
/usr/lib/jvm/java-6-openjdk/jre/bin/java
08051000-08052000 r--p 00008000 08:01 530845
/usr/lib/jvm/java-6-openjdk/jre/bin/java
08052000-08053000 rw-p 00009000 08:01 530845
/usr/lib/jvm/java-6-openjdk/jre/bin/java
09c70000-0a240000 rw-p 00000000 00:00 0 [heap]
70230000-70a60000 rw-p 00000000 00:00 0
70a60000-7a980000 rw-p 00000000 00:00 0
7a980000-7b9c3000 rw-p 00000000 00:00 0
7b9c3000-7ba23000 ---p 00000000 00:00 0
7ba23000-8f830000 rw-p 00000000 00:00 0
8f830000-90430000 rw-p 00000000 00:00 0
90430000-93830000 rw-p 00000000 00:00 0
93830000-93f7b000 r--s 00001000 08:01 521813
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/classes.jsa
93f7b000-94230000 rw-p 00000000 00:00 0
94230000-9496c000 rw-p 0074c000 08:01 521813
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/classes.jsa
9496c000-94e30000 rw-p 00000000 00:00 0
94e30000-94f2a000 rw-p 00e88000 08:01 521813
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/classes.jsa
94f2a000-95230000 rw-p 00000000 00:00 0
95230000-95238000 r-xs 00f82000 08:01 521813
/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/classes.jsa
95238000-95630000 rw-p 00000000 00:00 0
b4b00000-b4c00000 rw-p 00000000 00:00 0
b4c76000-b4c7a000 r--s 0002a000 08:01 869521
/home/pats/River/lib/tools.jar
b4c85000-b4c98000 r--s 000b2000 08:01 869515
/home/pats/River/lib/jsk-platform.jar
b4c9c000-b4c9e000 r--s 00008000 08:01 865055
/home/pats/River/lib/asm-commons-3.2.jar
b4c9e000-b4c9f000 r--s 0000a000 08:01 865056
/home/pats/River/lib/asm-3.2.jar
b4c9f000-b4ca1000 r--s 00013000 08:01 553668
/usr/lib/jvm/java-6-openjdk/jre/lib/jce.jar
b4ca1000-b4ca3000 r--s 00013000 08:01 553668
/usr/lib/jvm/java-6-openjdk/jre/lib/jce.jar
b4ca4000-b4cab000 r--s 00101000 08:01 553679
/usr/lib/jvm/java-6-openjdk/jre/lib/resources.jar
b4cab000-b4cbf000 r--s 000d8000 08:01 435856
/home/pats/River/test/lib/mockito-all-1.7.jar
b4cbf000-b4cc5000 r--s 00030000 08:01 435855
/home/pats/River/test/lib/junit-4.6.jar
b4cc5000-b4ccb000 r--s 00049000 08:01 436091
/home/pats/River/test/lib/cglib-nodep-2.2.jar
b4ccb000-b4cce000 ---p 00000000 00:00 0
b4cce000-b4d1c000 rw-p 00000000 00:00 0
b4d1c000-b4d1f000 ---p 00000000 00:00 0
b4d1f000-b4d6d000 rw-p 00000000 00:00 0
b4d6d000-b4d70000 ---p 00000000 00:00 0
b4d70000-b4dbe000 rw-p 00000000 00:00 0
b4dbe000-b4e1e000 r--s 00db5000 08:01 530923
/usr/lib/jvm/java-6-openjdk/lib/tools.jar
b4e1e000-b4e1f000 r--s 00001000 08:01 262367
/usr/share/java/ant-antlr-1.7.1.jar
b4e1f000-b4e22000 r--s 00018000 08:01 307623
/usr/share/java/junit-3.8.2.jar
b4e22000-b4e23000 r--s 00001000 08:01 262378
/usr/share/java/ant-jmf-1.7.1.jar
b4e23000-b4e24000 r--s 00000000 08:01 262370
/usr/share/java/ant-apache-log4j-1.7.1.jar
b4e24000-b4e26000 r--s 00006000 08:01 262379
/usr/share/java/ant-jsch-1.7.1.jar
b4e26000-b4e2e000 r--s 00062000 08:01 262381
/usr/share/java/ant-nodeps-1.7.1.jar
b4e2e000-b4e2f000 ---p 00000000 00:00 0
b4e2f000-b4eaf000 rw-p 00000000 00:00 0
b4eaf000-b4eb2000 ---p 00000000 00:00 0
b4eb2000-b4f00000 rw-p 00000000 00:00 0
b4f00000-b4ffc000 rw-p 00000000 00:00 0
b4ffc000-b5000000 ---p 00000000 00:00 0
b5000000-b5001000 r--s 00004000 08:01 435877
/home/pats/River/test/lib/MultithreadedTC-1.01.jar
b5001000-b5003000 r--s 0000a000 08:01 262375
/usr/share/java/ant-commons-net-1.7.1.jar
b5003000-b5005000 r--s 00008000 08:01 262371
/usr/share/java/ant-apache-oro-1.7.1.jar
b5005000-b5006000 r--s 00001000 08:01 262383
/usr/share/java/ant-trax-1.7.1.jar
b5006000-b5007000 r--s 00000000 08:01 262372
/usr/share/java/ant-apache-regexp-1.7.1.jar
b5007000-b5008000 r--s 00001000 08:01 262382
/usr/share/java/ant-swing-1.7.1.jar
b5008000-b5009000 r--s 00002000 08:01 262358
/usr/share/java/ant-launcher-1.7.1.jar
b5009000-b500b000 r--s 00015000 08:01 262380
/usr/share/java/ant-junit-1.7.1.jar
b500b000-b500c000 r--s 00000000 08:01 262373
/usr/share/java/ant-apache-resolver-1.7.1.jar
b500c000-b500d000 r--s 00000000 08:01 262374
/usr/share/java/ant-commons-logging-1.7.1.jar
b500d000-b500f000 r--s 00001000 08:01 262368
/usr/share/java/ant-apache-bcel-1.7.1.jar
b500f000-b5023000 r--s 00135000 08:01 262357
/usr/share/java/ant-1.7.1.jar
b5023000-b5024000 r--s 00001000 08:01 262377
/usr/share/java/ant-jdepend-1.7.1.jar
b5024000-b5025000 r--s 00001000 08:01 262376
/usr/share/java/ant-javamail-1.7.1.jar
b5025000-b503d000 r--s 00114000 08:01 262204
/usr/share/java/xercesImpl-2.9.1.jar
b503d000-b5045000 r--s 0002d000 08:01 531960
/usr/share/maven-repo/javax/xml/jaxp-api/1.3/jaxp-api-1.3.jar
b5045000-b504e000 r--s 00065000 08:01 307118
/usr/share/java/gnome-java-bridge.jar
b504e000-b5051000 ---p 00000000 00:00 0
b5051000-b50cf000 rw-p 00000000 00:00 0
b50cf000-b50d2000 ---p 00000000 00:00 0
b50d2000-b5120000 rw-p 00000000 00:00 0
b5120000-b5127000 r--s 00000000 08:01 140256
/usr/lib/gconv/gconv-modules.cache
b5127000-b5166000 r--p 00000000 08:01 140852
/usr/lib/locale/en_US.utf8/LC_CTYPE
b5166000-b5169000 ---p 00000000 00:00 0
b5169000-b51b7000 rw-p 00000000 00:00 0
b51b7000-b51ba000 ---p 00000000 00:00 0
b51ba000-b5208000 rw-p 00000000 00:00 0
b5208000-b5209000 ---p 00000000 00:00 0
b5209000-b52bc000 rw-p 00000000 00:00 0
b52bc000-b544f000 r--s 03918000 08:01 530784
/usr/lib/jvm/java-6-openjdk/jre/lib/rt.jar
b544f000-b5463000 rw-p 00000000 00:00 0
b5463000-b547d000 rw-p 00000000 00:00 0
b547d000-b5486000 rw-p 00000000 00:00 0
b5486000-b5525000 rw-p 00000000 00:00 0
b5525000-b552a000 rw-p 00000000 00:00 0
b552a000-b5578000 rw-p 00000000 00:00 0
b5578000-b5581000 rw-p 00000000 00:00 0
b5581000-b5620000 rw-p 00000000 00:00 0
b5620000-b5626000 rw-p 00000000 00:00 0
b5626000-b5640000 rw-p 00000000 00:00 0
b5640000-b565a000 rw-p 00000000 00:00 0
b565a000-b56cc000 rw-p 00000000 00:00 0
b56cc000-b5a34000 rwxp 00000000 00:00 0
b5a34000-b76cc000 rw-p 00000000 00:00 0
b76cc000-b76cf000 ---p 00000000 00:00 0
b76cf000-b7720000 rw-p 00000000 00:00 0
b7720000-b7721000 r--s 00000000 08:01 262369
/usr/share/java/ant-apache-bsf-1.7.1.jar
b7721000-b7722000 r--s 00002000 08:01 262358
/usr/share/java/ant-launcher-1.7.1.jar
b7722000-b7725000 r--s 0000f000 08:01 535254
/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar
b7725000-b772d000 rw-s 00000000 08:01 225436 /tmp/hsperfdata_pats/1641
b772d000-b772e000 rw-p 00000000 00:00 0
b772e000-b772f000 r--p 00000000 00:00 0
b772f000-b7731000 rw-p 00000000 00:00 0
bfba2000-bfbb7000 rw-p 00000000 00:00 0 [stack]
VM Arguments:
jvm_args: -Dant.home=/usr/share/ant -Dant.library.dir=/usr/share/ant/lib
java_command: org.apache.tools.ant.launch.Launcher -cp all.build
Launcher Type: SUN_STANDARD
Environment Variables:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
USERNAME=pats
LD_LIBRARY_PATH=/usr/lib/jvm/java-6-openjdk/jre/lib/i386/client:/usr/lib/jvm/java-6-openjdk/jre/lib/i386:/usr/lib/jvm/java-6-openjdk/jre/../lib/i386
SHELL=/bin/bash
DISPLAY=:0.0
Signal Handlers:
SIGSEGV: [libjvm.so+0x3af300], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x3af300], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x2d9380], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x2d9380], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x2d9380], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x2d9380], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x2d8a70], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x2db220], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: [libjvm.so+0x2db220], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGTERM: [libjvm.so+0x2db220], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x2db220], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Ubuntu 10.04 (lucid)
uname:Linux 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC
2010 i686
libc:glibc 2.11.1 NPTL 2.11.1
rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity
load average:0.62 0.30 0.21
CPU:total 8 (8 cores per cpu, 1 threads per core) family 6 model 23
stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 1026084k(17288k free), swap 747512k(747416k free)
vm_info: OpenJDK Client VM (16.0-b13) for linux-x86 JRE (1.6.0_18-b18),
built on Jul 27 2010 11:22:25 by "buildd" with gcc 4.4.3
time: Sat Sep 25 01:40:35 2010
elapsed time: 28 seconds
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
I've noticed as well that sometimes, the build crashes the VM.
I've seen this (JVM crash) happening at multiple, unrelated points in the
build process (sometimes at preferredlistgen execution, sometimes while
jarring, sometimes while generating javadoc, sometimes during QA testing
...) Haven't been able to consistently reproduce either.
There are some Hudson builds that failed with a JVM crash, during the build
itself, not during QA testing.
I have been planning to log a problem ticket at Oracle for these JVM
crashes. So, if anyone comes across them, please post the hs_err_pidxxxx.log
file that is outputed with the JVM crashes.
Also, there is an (unrelated) exception happening during QA docs generation,
wanted to also log that issue at Oracle.
Everybody agree to log these crashes at Oracle, when they occur again?
Thanks
Jonathan
2010/9/23 Tom Hobbs <tv...@googlemail.com>
> Maybe this is a red herring, but it's nothing to do with your use of
> OpenJDK, is it? Are we restricted to the Sun JDK?
>
> On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan <pa...@acm.org> wrote:
>
> > On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
> >
> >> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
> >> NullPointerException in
> >> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> >>
> >> A re-run of the qa.run test that first got the failure did not repeat
> >> it. I have started repeatedly running the one test, and got one more
> >> failure out of 568 runs, so far. I am continuing the repeated run to get
> >> a more statistically significant estimate of the failure rate.
> >>
> >> This is obviously going to be difficult to debug, or even to know if we
> >> have fixed it after a change. The bug may have existed for a long time.
> >>
> >
> > I got the following failure on the trunk head revision, with SDM's
> > addProxyReg modified with a couple of Thread.sleep calls. Note that this
> > failure is one in thousands of runs, so don't count on reproducing it,
> e.g.
> > to get more logging data.
> >
> > Any ideas what went wrong?
> >
> >
> > [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> > [java] Time is Wed Sep 22 20:13:06 PDT 2010
> > [java] Starting test in separate process with command:
> > [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
> >
> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
> > -cp
> >
> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
> > -client
> >
> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> > -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
> > -Dcom.sun.jini.jsk.home=/home/pats/River
> > -Dcom.sun.jini.qa.home=/home/pats/River/qa
> >
> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
> > -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
> > -Dcom.sun.jini.qa.harness.runjiniserver=true
> > -Dcom.sun.jini.qa.harness.runkitserver=true
> >
> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
> > -Dcom.sun.jini.qa.harness.testhosts=
> >
> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
> > -Dcom.sun.jini.test.home=/home/pats/River/qa
> -Dcom.sun.jini.test.port=8082
> >
> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
> >
> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> > com.sun.jini.qa.harness.MasterTest
> > com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> > [java]
> > [java] TIME: 8:13:06 PM
> > [java]
> > [java] MasterTest.doTest INFO:
> > [java] ============================== CALLING SETUP()
> > ==============================
> > [java]
> > [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> > [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
> > 8081]
> > [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> > [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
> > 8080]
> > [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> > [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
> > 8082]
> > [java] MasterTest.doTest INFO:
> > [java] =============================== CALLING RUN()
> > ===============================
> > [java]
> > [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
> > com.sun.jini.reggie.RegistrarImpl init
> > [java] NonActGrp-out: INFO: started Reggie:
> > 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
> > [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
> > ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
> > [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
> > com.sun.jini.mercury.MailboxImpl doInit
> > [java] NonActGrp-out: INFO: Mercury started:
> > com.sun.jini.mercury.TransientMercuryImpl@2b323e
> > [java] MailboxTestBase.getPullMailbox INFO: Got reference to
> > PullEventMailbox service:
> > com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
> > [java] MailboxTestBase.getPullRegistration INFO: Got reference to
> > MailboxPullRegistration object:
> > com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
> > [java] MailboxTestBase.getPullRegistration INFO: registration proxy
> > preparer: BasicProxyPreparer[]
> > [java] MailboxTestBase.getPullRegistration INFO: Prepared
> > registration proxy:
> > com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
> > [java] MailboxTestBase.getPullMailboxLease INFO: Calling
> > getPullMailboxLease()
> > [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
> > preparer: BasicProxyPreparer[]
> > [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
> > lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
> >
> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936
> ]]]]
> > landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
> > com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
> > [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> > granted
> > [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
> > 20:16:09 PDT 2010
> > [java] MailboxTestBase.getPullMailboxListener INFO: Calling
> > getPullMailboxListener()
> > [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
> > listener preparer: BasicProxyPreparer[]
> > [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
> > mailbox listener proxy:
> > com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
> > [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> > granted
> > [java] MailboxTestUtils: createPullListeners: created 1
> > TestPullListener(s)
> > [java] EMSRIFT_PULL.run INFO: Generating 5 events
> > [java] EMSRIFT_PULL.run INFO: Wating for event delivery
> > [java]
> > [java] TIME: 8:13:19 PM
> > [java]
> > [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
> > [java] EMSRIFT_PULL.run INFO: Verifying events
> > [java] NonActGrp-out: ::verifyEvent() verifying
> > [java] NonActGrp-out: Desired event was found:
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> > [java] NonActGrp-out: Events
> > are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[
> 127.0.1.1:55936
> > ]]]]]}
> > [java] NonActGrp-out: ::verifyEvent() verifying
> > [java] NonActGrp-out: Desired event was found:
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> > [java] NonActGrp-out: Events
> > are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]],
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> >
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[
> 127.0.1.1:55936
> > ]]]]]}
> > [java] NonActGrp-out: ::verifyEvent() verifying
> > [java] NonActGrp-out: Desired event was found:
> > com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> > [java] #
> > [java] # A fatal error has been detected by the Java Runtime
> > Environment:
> > [java] #
> > [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling
> registration
> > lease
> > [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
> > [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
> > exception in compiled code")
> > [java] #
> > [java] # JRE version: 6.0_18-b18
> > [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
> > linux-x86 )
> > [java] # Derivative: IcedTea6 1.8.1
> > [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
> > [java] # An error report file with more information is saved as:
> > [java] # /home/pats/River/qa/hs_err_pid6166.log
> > [java] EMSRIFT_PULL.run INFO: Generating 5 more events
> > [java] #
> > [java] # If you would like to submit a bug report, please include
> > [java] # instructions how to reproduce the bug and visit:
> > [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
> > [java] #
> > [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
> > [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
> > [java]
> > [java] TIME: 8:13:19 PM
> > [java]
> > [java] Test process was destroyed and returned code 134
> > [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> > [java] Test Failed: Test VM terminated without returning test status
> >
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I start each VirtualBox with 8 GB of disk space, but also tell it it can
increase as necessary. I have 1.54 TB of free space on my physical disk,
so it is unlikely to run out soon.
The JDK I used for the failure I posted is the one you get if you go
through the Ubuntu application installation process rather than
downloading from the Oracle site. If we don't intend to work with it, we
should make that very clear. However, my preference is to avoid doing
anything that might be affected by which JDK is being used.
Patricia
On 9/23/2010 6:58 AM, Peter Firmstone wrote:
> Patricia,
>
> Your using IcedTea, that's awesome, I'm impressed, I installed it on a
> Nokia N900, tried running River, but ran out of temporary file space, I
> need to re-partition it and try again.
>
> Cheers,
>
> Peter.
>
> Tom Hobbs wrote:
>> Maybe this is a red herring, but it's nothing to do with your use of
>> OpenJDK, is it? Are we restricted to the Sun JDK?
>>
>> On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan <pa...@acm.org> wrote:
>>
>>> On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
>>>
>>>> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
>>>> NullPointerException in
>>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>>>
>>>> A re-run of the qa.run test that first got the failure did not repeat
>>>> it. I have started repeatedly running the one test, and got one more
>>>> failure out of 568 runs, so far. I am continuing the repeated run to
>>>> get
>>>> a more statistically significant estimate of the failure rate.
>>>>
>>>> This is obviously going to be difficult to debug, or even to know if we
>>>> have fixed it after a change. The bug may have existed for a long time.
>>>>
>>> I got the following failure on the trunk head revision, with SDM's
>>> addProxyReg modified with a couple of Thread.sleep calls. Note that this
>>> failure is one in thousands of runs, so don't count on reproducing
>>> it, e.g.
>>> to get more logging data.
>>>
>>> Any ideas what went wrong?
>>>
>>>
>>> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java] Time is Wed Sep 22 20:13:06 PDT 2010
>>> [java] Starting test in separate process with command:
>>> [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
>>> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
>>>
>>> -cp
>>> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
>>>
>>> -client
>>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>>>
>>> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
>>> -Dcom.sun.jini.jsk.home=/home/pats/River
>>> -Dcom.sun.jini.qa.home=/home/pats/River/qa
>>> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
>>>
>>> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
>>> -Dcom.sun.jini.qa.harness.runjiniserver=true
>>> -Dcom.sun.jini.qa.harness.runkitserver=true
>>> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
>>>
>>> -Dcom.sun.jini.qa.harness.testhosts=
>>> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
>>>
>>> -Dcom.sun.jini.test.home=/home/pats/River/qa
>>> -Dcom.sun.jini.test.port=8082
>>> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
>>>
>>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>>>
>>> com.sun.jini.qa.harness.MasterTest
>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java]
>>> [java] TIME: 8:13:06 PM
>>> [java]
>>> [java] MasterTest.doTest INFO:
>>> [java] ============================== CALLING SETUP()
>>> ==============================
>>> [java]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>>> 8081]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
>>> 8080]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>>> 8082]
>>> [java] MasterTest.doTest INFO:
>>> [java] =============================== CALLING RUN()
>>> ===============================
>>> [java]
>>> [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
>>> com.sun.jini.reggie.RegistrarImpl init
>>> [java] NonActGrp-out: INFO: started Reggie:
>>> 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
>>> [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
>>> ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
>>> [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
>>> com.sun.jini.mercury.MailboxImpl doInit
>>> [java] NonActGrp-out: INFO: Mercury started:
>>> com.sun.jini.mercury.TransientMercuryImpl@2b323e
>>> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
>>> PullEventMailbox service:
>>> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
>>> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
>>> MailboxPullRegistration object:
>>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>>> [java] MailboxTestBase.getPullRegistration INFO: registration proxy
>>> preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullRegistration INFO: Prepared
>>> registration proxy:
>>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>>> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
>>> getPullMailboxLease()
>>> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
>>> preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
>>> lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
>>> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936]]]]
>>>
>>> landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
>>> com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
>>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>>> granted
>>> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
>>> 20:16:09 PDT 2010
>>> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
>>> getPullMailboxListener()
>>> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
>>> listener preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
>>> mailbox listener proxy:
>>> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
>>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>>> granted
>>> [java] MailboxTestUtils: createPullListeners: created 1
>>> TestPullListener(s)
>>> [java] EMSRIFT_PULL.run INFO: Generating 5 events
>>> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
>>> [java]
>>> [java] TIME: 8:13:19 PM
>>> [java]
>>> [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
>>> [java] EMSRIFT_PULL.run INFO: Verifying events
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>> [java] NonActGrp-out: Events
>>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>>
>>> ]]]]]}
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>> [java] NonActGrp-out: Events
>>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>>>
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>>
>>> ]]]]]}
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>> [java] #
>>> [java] # A fatal error has been detected by the Java Runtime
>>> Environment:
>>> [java] #
>>> [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling registration
>>> lease
>>> [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
>>> [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
>>> exception in compiled code")
>>> [java] #
>>> [java] # JRE version: 6.0_18-b18
>>> [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
>>> linux-x86 )
>>> [java] # Derivative: IcedTea6 1.8.1
>>> [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
>>> [java] # An error report file with more information is saved as:
>>> [java] # /home/pats/River/qa/hs_err_pid6166.log
>>> [java] EMSRIFT_PULL.run INFO: Generating 5 more events
>>> [java] #
>>> [java] # If you would like to submit a bug report, please include
>>> [java] # instructions how to reproduce the bug and visit:
>>> [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
>>> [java] #
>>> [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
>>> [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
>>> [java]
>>> [java] TIME: 8:13:19 PM
>>> [java]
>>> [java] Test process was destroyed and returned code 134
>>> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java] Test Failed: Test VM terminated without returning test status
>>>
>>
>
>
Re: Request for testing help
Posted by Peter Firmstone <ji...@zeus.net.au>.
Patricia,
Your using IcedTea, that's awesome, I'm impressed, I installed it on a
Nokia N900, tried running River, but ran out of temporary file space, I
need to re-partition it and try again.
Cheers,
Peter.
Tom Hobbs wrote:
> Maybe this is a red herring, but it's nothing to do with your use of
> OpenJDK, is it? Are we restricted to the Sun JDK?
>
> On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan <pa...@acm.org> wrote:
>
>
>> On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
>>
>>
>>> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
>>> NullPointerException in
>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>>
>>> A re-run of the qa.run test that first got the failure did not repeat
>>> it. I have started repeatedly running the one test, and got one more
>>> failure out of 568 runs, so far. I am continuing the repeated run to get
>>> a more statistically significant estimate of the failure rate.
>>>
>>> This is obviously going to be difficult to debug, or even to know if we
>>> have fixed it after a change. The bug may have existed for a long time.
>>>
>>>
>> I got the following failure on the trunk head revision, with SDM's
>> addProxyReg modified with a couple of Thread.sleep calls. Note that this
>> failure is one in thousands of runs, so don't count on reproducing it, e.g.
>> to get more logging data.
>>
>> Any ideas what went wrong?
>>
>>
>> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java] Time is Wed Sep 22 20:13:06 PDT 2010
>> [java] Starting test in separate process with command:
>> [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
>> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
>> -cp
>> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
>> -client
>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
>> -Dcom.sun.jini.jsk.home=/home/pats/River
>> -Dcom.sun.jini.qa.home=/home/pats/River/qa
>> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
>> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
>> -Dcom.sun.jini.qa.harness.runjiniserver=true
>> -Dcom.sun.jini.qa.harness.runkitserver=true
>> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
>> -Dcom.sun.jini.qa.harness.testhosts=
>> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
>> -Dcom.sun.jini.test.home=/home/pats/River/qa -Dcom.sun.jini.test.port=8082
>> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>> com.sun.jini.qa.harness.MasterTest
>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java]
>> [java] TIME: 8:13:06 PM
>> [java]
>> [java] MasterTest.doTest INFO:
>> [java] ============================== CALLING SETUP()
>> ==============================
>> [java]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>> 8081]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
>> 8080]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>> 8082]
>> [java] MasterTest.doTest INFO:
>> [java] =============================== CALLING RUN()
>> ===============================
>> [java]
>> [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
>> com.sun.jini.reggie.RegistrarImpl init
>> [java] NonActGrp-out: INFO: started Reggie:
>> 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
>> [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
>> ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
>> [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
>> com.sun.jini.mercury.MailboxImpl doInit
>> [java] NonActGrp-out: INFO: Mercury started:
>> com.sun.jini.mercury.TransientMercuryImpl@2b323e
>> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
>> PullEventMailbox service:
>> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
>> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
>> MailboxPullRegistration object:
>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>> [java] MailboxTestBase.getPullRegistration INFO: registration proxy
>> preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullRegistration INFO: Prepared
>> registration proxy:
>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
>> getPullMailboxLease()
>> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
>> preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
>> lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
>> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936]]]]
>> landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
>> com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>> granted
>> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
>> 20:16:09 PDT 2010
>> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
>> getPullMailboxListener()
>> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
>> listener preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
>> mailbox listener proxy:
>> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>> granted
>> [java] MailboxTestUtils: createPullListeners: created 1
>> TestPullListener(s)
>> [java] EMSRIFT_PULL.run INFO: Generating 5 events
>> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
>> [java]
>> [java] TIME: 8:13:19 PM
>> [java]
>> [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
>> [java] EMSRIFT_PULL.run INFO: Verifying events
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> [java] NonActGrp-out: Events
>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>> ]]]]]}
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> [java] NonActGrp-out: Events
>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>> ]]]]]}
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> [java] #
>> [java] # A fatal error has been detected by the Java Runtime
>> Environment:
>> [java] #
>> [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling registration
>> lease
>> [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
>> [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
>> exception in compiled code")
>> [java] #
>> [java] # JRE version: 6.0_18-b18
>> [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
>> linux-x86 )
>> [java] # Derivative: IcedTea6 1.8.1
>> [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
>> [java] # An error report file with more information is saved as:
>> [java] # /home/pats/River/qa/hs_err_pid6166.log
>> [java] EMSRIFT_PULL.run INFO: Generating 5 more events
>> [java] #
>> [java] # If you would like to submit a bug report, please include
>> [java] # instructions how to reproduce the bug and visit:
>> [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
>> [java] #
>> [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
>> [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
>> [java]
>> [java] TIME: 8:13:19 PM
>> [java]
>> [java] Test process was destroyed and returned code 134
>> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java] Test Failed: Test VM terminated without returning test status
>>
>>
>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/23/2010 8:00 AM, Jonathan Costers wrote:
> 2010/9/23 Patricia Shanahan<pa...@acm.org>
...
>> I would like to see MS-Windows added as soon as possible. It is a rather
>> popular operating system. I recently saw a major regression running QA on
>> WindowsXP, so that I am currently limited to my VirtualBox environments.
>>
>
> For me, the whole suite passes, only we cannot have any spaces in any paths
> (JDK, Ant, river trunk, etc.), as I mentioned a while ago.
It had been working for me previously with spaces in the JDK path, but I
just did a re-run with a space-free JDK install, and it still fails. My
suspicion is that something else has got messed up on my system. I did
try rebooting, then doing a clean build. Any other suggestions for reset
procedures?
Patricia
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/9/23 Patricia Shanahan <pa...@acm.org>
> On 9/23/2010 7:25 AM, Jonathan Costers wrote:
>
>> 2010/9/23 Patricia Shanahan<pa...@acm.org>
>>
>> I'll set up another VirtualBox Ubuntu and use the Sun JDK to build and
>>> run
>>> in it. If the test ever fails I'll know the JDK is not the issue. If it
>>> does
>>> not fail, the best I'll be able to do is estimate the posterior
>>> probability
>>> of a failure rate due to similar probability of failure to the observed
>>> rate
>>> on OpenJDK, given 0 observed failures on N runs.
>>>
>>>
>> One question, how much RAM are you assigning to your VMs?
>>
>
> 1 GB per VirtualBox. I also tell them there are 8 processors, so they can
> use all the hardware threads there are on my computer.
>
>
>
>> Also, it may be interesting to note is that on Hudson, when using the
>> ubuntu
>> executors, the QA test suite consistently passes.
>> On the solaris executors however, we consistently get one failing test.
>> That is why you are seeing failed and passed builds intermittently being
>> reported by Hudson.
>>
>> Would anybody oppose to split the QA build again:
>> - one build only running on solaris executors (this one should
>> consistently
>> fail, for now)
>> - one build only running on ubuntu executors (this one should consistently
>> pass)
>> - both are mutually exclusive, so if one is running, the other must wait
>> (to
>> not bring the Apache infrastructure to its knees ...)
>> - eventually, we can look at running the QA suite on a windows(!) executor
>> as well ...<ducks>
>>
>
> I would like to see MS-Windows added as soon as possible. It is a rather
> popular operating system. I recently saw a major regression running QA on
> WindowsXP, so that I am currently limited to my VirtualBox environments.
>
For me, the whole suite passes, only we cannot have any spaces in any paths
(JDK, Ant, river trunk, etc.), as I mentioned a while ago.
> Patricia
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/23/2010 7:25 AM, Jonathan Costers wrote:
> 2010/9/23 Patricia Shanahan<pa...@acm.org>
>
>> I'll set up another VirtualBox Ubuntu and use the Sun JDK to build and run
>> in it. If the test ever fails I'll know the JDK is not the issue. If it does
>> not fail, the best I'll be able to do is estimate the posterior probability
>> of a failure rate due to similar probability of failure to the observed rate
>> on OpenJDK, given 0 observed failures on N runs.
>>
>
> One question, how much RAM are you assigning to your VMs?
1 GB per VirtualBox. I also tell them there are 8 processors, so they
can use all the hardware threads there are on my computer.
>
> Also, it may be interesting to note is that on Hudson, when using the ubuntu
> executors, the QA test suite consistently passes.
> On the solaris executors however, we consistently get one failing test.
> That is why you are seeing failed and passed builds intermittently being
> reported by Hudson.
>
> Would anybody oppose to split the QA build again:
> - one build only running on solaris executors (this one should consistently
> fail, for now)
> - one build only running on ubuntu executors (this one should consistently
> pass)
> - both are mutually exclusive, so if one is running, the other must wait (to
> not bring the Apache infrastructure to its knees ...)
> - eventually, we can look at running the QA suite on a windows(!) executor
> as well ...<ducks>
I would like to see MS-Windows added as soon as possible. It is a rather
popular operating system. I recently saw a major regression running QA
on WindowsXP, so that I am currently limited to my VirtualBox environments.
Patricia
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/9/23 Patricia Shanahan <pa...@acm.org>
> I'll set up another VirtualBox Ubuntu and use the Sun JDK to build and run
> in it. If the test ever fails I'll know the JDK is not the issue. If it does
> not fail, the best I'll be able to do is estimate the posterior probability
> of a failure rate due to similar probability of failure to the observed rate
> on OpenJDK, given 0 observed failures on N runs.
>
One question, how much RAM are you assigning to your VMs?
Also, it may be interesting to note is that on Hudson, when using the ubuntu
executors, the QA test suite consistently passes.
On the solaris executors however, we consistently get one failing test.
That is why you are seeing failed and passed builds intermittently being
reported by Hudson.
Would anybody oppose to split the QA build again:
- one build only running on solaris executors (this one should consistently
fail, for now)
- one build only running on ubuntu executors (this one should consistently
pass)
- both are mutually exclusive, so if one is running, the other must wait (to
not bring the Apache infrastructure to its knees ...)
- eventually, we can look at running the QA suite on a windows(!) executor
as well ... <ducks>
> I'm prejudiced, because I don't trust some of the concurrency and retry
> handling in ServiceDiscoveryManager and JoinManager, and this thing smells
> to me like a low probability concurrency failure. At the failure rates I'm
> seeing, measured now in thousands of runs per failure, it could have been
> there for a long time.
>
I have the same impression.
This code was written in the 1.4 era, with limited concurrency "tools"
available. So there's probably some room for improvement in that area.
> Incidentally, it just failed again, this time back to the
> NullPointerException.
>
> Patricia
>
>
>
> On 9/23/2010 6:15 AM, Tom Hobbs wrote:
>
>> Maybe this is a red herring, but it's nothing to do with your use of
>> OpenJDK, is it? Are we restricted to the Sun JDK?
>>
>> On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan<pa...@acm.org> wrote:
>>
>> On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
>>>
>>> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
>>>> NullPointerException in
>>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>>>
>>>> A re-run of the qa.run test that first got the failure did not repeat
>>>> it. I have started repeatedly running the one test, and got one more
>>>> failure out of 568 runs, so far. I am continuing the repeated run to get
>>>> a more statistically significant estimate of the failure rate.
>>>>
>>>> This is obviously going to be difficult to debug, or even to know if we
>>>> have fixed it after a change. The bug may have existed for a long time.
>>>>
>>>>
>>> I got the following failure on the trunk head revision, with SDM's
>>> addProxyReg modified with a couple of Thread.sleep calls. Note that this
>>> failure is one in thousands of runs, so don't count on reproducing it,
>>> e.g.
>>> to get more logging data.
>>>
>>> Any ideas what went wrong?
>>>
>>>
>>> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java] Time is Wed Sep 22 20:13:06 PDT 2010
>>> [java] Starting test in separate process with command:
>>> [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
>>>
>>> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
>>> -cp
>>>
>>> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
>>> -client
>>>
>>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>>> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
>>> -Dcom.sun.jini.jsk.home=/home/pats/River
>>> -Dcom.sun.jini.qa.home=/home/pats/River/qa
>>>
>>> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
>>> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
>>> -Dcom.sun.jini.qa.harness.runjiniserver=true
>>> -Dcom.sun.jini.qa.harness.runkitserver=true
>>>
>>> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
>>> -Dcom.sun.jini.qa.harness.testhosts=
>>>
>>> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
>>> -Dcom.sun.jini.test.home=/home/pats/River/qa
>>> -Dcom.sun.jini.test.port=8082
>>>
>>> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
>>>
>>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>>> com.sun.jini.qa.harness.MasterTest
>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java]
>>> [java] TIME: 8:13:06 PM
>>> [java]
>>> [java] MasterTest.doTest INFO:
>>> [java] ============================== CALLING SETUP()
>>> ==============================
>>> [java]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>>> 8081]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
>>> 8080]
>>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>>> 8082]
>>> [java] MasterTest.doTest INFO:
>>> [java] =============================== CALLING RUN()
>>> ===============================
>>> [java]
>>> [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
>>> com.sun.jini.reggie.RegistrarImpl init
>>> [java] NonActGrp-out: INFO: started Reggie:
>>> 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
>>> [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
>>> ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
>>> [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
>>> com.sun.jini.mercury.MailboxImpl doInit
>>> [java] NonActGrp-out: INFO: Mercury started:
>>> com.sun.jini.mercury.TransientMercuryImpl@2b323e
>>> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
>>> PullEventMailbox service:
>>> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
>>> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
>>> MailboxPullRegistration object:
>>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>>> [java] MailboxTestBase.getPullRegistration INFO: registration proxy
>>> preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullRegistration INFO: Prepared
>>> registration proxy:
>>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>>> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
>>> getPullMailboxLease()
>>> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
>>> preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
>>> lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
>>>
>>> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936
>>> ]]]]
>>> landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
>>> com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
>>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>>> granted
>>> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
>>> 20:16:09 PDT 2010
>>> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
>>> getPullMailboxListener()
>>> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
>>> listener preparer: BasicProxyPreparer[]
>>> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
>>> mailbox listener proxy:
>>> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
>>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>>> granted
>>> [java] MailboxTestUtils: createPullListeners: created 1
>>> TestPullListener(s)
>>> [java] EMSRIFT_PULL.run INFO: Generating 5 events
>>> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
>>> [java]
>>> [java] TIME: 8:13:19 PM
>>> [java]
>>> [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
>>> [java] EMSRIFT_PULL.run INFO: Verifying events
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>> [java] NonActGrp-out: Events
>>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[
>>> 127.0.1.1:55936
>>> ]]]]]}
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>> [java] NonActGrp-out: Events
>>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>>> ]]]]],
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>>>
>>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[
>>> 127.0.1.1:55936
>>> ]]]]]}
>>> [java] NonActGrp-out: ::verifyEvent() verifying
>>> [java] NonActGrp-out: Desired event was found:
>>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>>> [java] #
>>> [java] # A fatal error has been detected by the Java Runtime
>>> Environment:
>>> [java] #
>>> [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling
>>> registration
>>> lease
>>> [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
>>> [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
>>> exception in compiled code")
>>> [java] #
>>> [java] # JRE version: 6.0_18-b18
>>> [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
>>> linux-x86 )
>>> [java] # Derivative: IcedTea6 1.8.1
>>> [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
>>> [java] # An error report file with more information is saved as:
>>> [java] # /home/pats/River/qa/hs_err_pid6166.log
>>> [java] EMSRIFT_PULL.run INFO: Generating 5 more events
>>> [java] #
>>> [java] # If you would like to submit a bug report, please include
>>> [java] # instructions how to reproduce the bug and visit:
>>> [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
>>> [java] #
>>> [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
>>> [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
>>> [java]
>>> [java] TIME: 8:13:19 PM
>>> [java]
>>> [java] Test process was destroyed and returned code 134
>>> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>> [java] Test Failed: Test VM terminated without returning test status
>>>
>>>
>>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I'm not aware of any such restriction, and I would expect that sort of
problem to cause more reproducible failures, but it's certainly worth
trying.
I'll set up another VirtualBox Ubuntu and use the Sun JDK to build and
run in it. If the test ever fails I'll know the JDK is not the issue. If
it does not fail, the best I'll be able to do is estimate the posterior
probability of a failure rate due to similar probability of failure to
the observed rate on OpenJDK, given 0 observed failures on N runs.
I'm prejudiced, because I don't trust some of the concurrency and retry
handling in ServiceDiscoveryManager and JoinManager, and this thing
smells to me like a low probability concurrency failure. At the failure
rates I'm seeing, measured now in thousands of runs per failure, it
could have been there for a long time.
Incidentally, it just failed again, this time back to the
NullPointerException.
Patricia
On 9/23/2010 6:15 AM, Tom Hobbs wrote:
> Maybe this is a red herring, but it's nothing to do with your use of
> OpenJDK, is it? Are we restricted to the Sun JDK?
>
> On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan<pa...@acm.org> wrote:
>
>> On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
>>
>>> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
>>> NullPointerException in
>>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>>
>>> A re-run of the qa.run test that first got the failure did not repeat
>>> it. I have started repeatedly running the one test, and got one more
>>> failure out of 568 runs, so far. I am continuing the repeated run to get
>>> a more statistically significant estimate of the failure rate.
>>>
>>> This is obviously going to be difficult to debug, or even to know if we
>>> have fixed it after a change. The bug may have existed for a long time.
>>>
>>
>> I got the following failure on the trunk head revision, with SDM's
>> addProxyReg modified with a couple of Thread.sleep calls. Note that this
>> failure is one in thousands of runs, so don't count on reproducing it, e.g.
>> to get more logging data.
>>
>> Any ideas what went wrong?
>>
>>
>> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java] Time is Wed Sep 22 20:13:06 PDT 2010
>> [java] Starting test in separate process with command:
>> [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
>> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
>> -cp
>> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
>> -client
>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
>> -Dcom.sun.jini.jsk.home=/home/pats/River
>> -Dcom.sun.jini.qa.home=/home/pats/River/qa
>> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
>> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
>> -Dcom.sun.jini.qa.harness.runjiniserver=true
>> -Dcom.sun.jini.qa.harness.runkitserver=true
>> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
>> -Dcom.sun.jini.qa.harness.testhosts=
>> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
>> -Dcom.sun.jini.test.home=/home/pats/River/qa -Dcom.sun.jini.test.port=8082
>> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
>> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
>> com.sun.jini.qa.harness.MasterTest
>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java]
>> [java] TIME: 8:13:06 PM
>> [java]
>> [java] MasterTest.doTest INFO:
>> [java] ============================== CALLING SETUP()
>> ==============================
>> [java]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>> 8081]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
>> 8080]
>> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
>> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
>> 8082]
>> [java] MasterTest.doTest INFO:
>> [java] =============================== CALLING RUN()
>> ===============================
>> [java]
>> [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
>> com.sun.jini.reggie.RegistrarImpl init
>> [java] NonActGrp-out: INFO: started Reggie:
>> 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
>> [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
>> ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
>> [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
>> com.sun.jini.mercury.MailboxImpl doInit
>> [java] NonActGrp-out: INFO: Mercury started:
>> com.sun.jini.mercury.TransientMercuryImpl@2b323e
>> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
>> PullEventMailbox service:
>> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
>> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
>> MailboxPullRegistration object:
>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>> [java] MailboxTestBase.getPullRegistration INFO: registration proxy
>> preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullRegistration INFO: Prepared
>> registration proxy:
>> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
>> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
>> getPullMailboxLease()
>> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
>> preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
>> lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
>> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936]]]]
>> landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
>> com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>> granted
>> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
>> 20:16:09 PDT 2010
>> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
>> getPullMailboxListener()
>> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
>> listener preparer: BasicProxyPreparer[]
>> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
>> mailbox listener proxy:
>> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
>> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
>> granted
>> [java] MailboxTestUtils: createPullListeners: created 1
>> TestPullListener(s)
>> [java] EMSRIFT_PULL.run INFO: Generating 5 events
>> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
>> [java]
>> [java] TIME: 8:13:19 PM
>> [java]
>> [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
>> [java] EMSRIFT_PULL.run INFO: Verifying events
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> [java] NonActGrp-out: Events
>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>> ]]]]]}
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> [java] NonActGrp-out: Events
>> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
>> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
>> ]]]]]}
>> [java] NonActGrp-out: ::verifyEvent() verifying
>> [java] NonActGrp-out: Desired event was found:
>> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
>> [java] #
>> [java] # A fatal error has been detected by the Java Runtime
>> Environment:
>> [java] #
>> [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling registration
>> lease
>> [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
>> [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
>> exception in compiled code")
>> [java] #
>> [java] # JRE version: 6.0_18-b18
>> [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
>> linux-x86 )
>> [java] # Derivative: IcedTea6 1.8.1
>> [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
>> [java] # An error report file with more information is saved as:
>> [java] # /home/pats/River/qa/hs_err_pid6166.log
>> [java] EMSRIFT_PULL.run INFO: Generating 5 more events
>> [java] #
>> [java] # If you would like to submit a bug report, please include
>> [java] # instructions how to reproduce the bug and visit:
>> [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
>> [java] #
>> [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
>> [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
>> [java]
>> [java] TIME: 8:13:19 PM
>> [java]
>> [java] Test process was destroyed and returned code 134
>> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>> [java] Test Failed: Test VM terminated without returning test status
>>
>
Re: Request for testing help
Posted by Tom Hobbs <tv...@googlemail.com>.
Maybe this is a red herring, but it's nothing to do with your use of
OpenJDK, is it? Are we restricted to the Sun JDK?
On Thu, Sep 23, 2010 at 2:03 PM, Patricia Shanahan <pa...@acm.org> wrote:
> On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
>
>> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
>> NullPointerException in
>> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>>
>> A re-run of the qa.run test that first got the failure did not repeat
>> it. I have started repeatedly running the one test, and got one more
>> failure out of 568 runs, so far. I am continuing the repeated run to get
>> a more statistically significant estimate of the failure rate.
>>
>> This is obviously going to be difficult to debug, or even to know if we
>> have fixed it after a change. The bug may have existed for a long time.
>>
>
> I got the following failure on the trunk head revision, with SDM's
> addProxyReg modified with a couple of Thread.sleep calls. Note that this
> failure is one in thousands of runs, so don't count on reproducing it, e.g.
> to get more logging data.
>
> Any ideas what went wrong?
>
>
> [java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java] Time is Wed Sep 22 20:13:06 PDT 2010
> [java] Starting test in separate process with command:
> [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
> -Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
> -cp
> /home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
> -client
> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> -Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
> -Dcom.sun.jini.jsk.home=/home/pats/River
> -Dcom.sun.jini.qa.home=/home/pats/River/qa
> -Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
> -Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
> -Dcom.sun.jini.qa.harness.runjiniserver=true
> -Dcom.sun.jini.qa.harness.runkitserver=true
> -Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
> -Dcom.sun.jini.qa.harness.testhosts=
> -Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
> -Dcom.sun.jini.test.home=/home/pats/River/qa -Dcom.sun.jini.test.port=8082
> -Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
> -Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
> com.sun.jini.qa.harness.MasterTest
> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java]
> [java] TIME: 8:13:06 PM
> [java]
> [java] MasterTest.doTest INFO:
> [java] ============================== CALLING SETUP()
> ==============================
> [java]
> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
> 8081]
> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
> 8080]
> [java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
> [java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
> 8082]
> [java] MasterTest.doTest INFO:
> [java] =============================== CALLING RUN()
> ===============================
> [java]
> [java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
> com.sun.jini.reggie.RegistrarImpl init
> [java] NonActGrp-out: INFO: started Reggie:
> 3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
> [LDSLookupServiceGroup_UbantuDesktop_1285211586313],
> ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
> [java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
> com.sun.jini.mercury.MailboxImpl doInit
> [java] NonActGrp-out: INFO: Mercury started:
> com.sun.jini.mercury.TransientMercuryImpl@2b323e
> [java] MailboxTestBase.getPullMailbox INFO: Got reference to
> PullEventMailbox service:
> com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
> [java] MailboxTestBase.getPullRegistration INFO: Got reference to
> MailboxPullRegistration object:
> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
> [java] MailboxTestBase.getPullRegistration INFO: registration proxy
> preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullRegistration INFO: Prepared
> registration proxy:
> com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
> [java] MailboxTestBase.getPullMailboxLease INFO: Calling
> getPullMailboxLease()
> [java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
> preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
> lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
> landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936]]]]
> landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
> com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> granted
> [java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
> 20:16:09 PDT 2010
> [java] MailboxTestBase.getPullMailboxListener INFO: Calling
> getPullMailboxListener()
> [java] MailboxTestBase.getPullMailboxListener INFO: mailbox
> listener preparer: BasicProxyPreparer[]
> [java] MailboxTestBase.getPullMailboxListener INFO: Prepared
> mailbox listener proxy:
> com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
> [java] MailboxTestBase.checkLease INFO: Lease request for 180000
> granted
> [java] MailboxTestUtils: createPullListeners: created 1
> TestPullListener(s)
> [java] EMSRIFT_PULL.run INFO: Generating 5 events
> [java] EMSRIFT_PULL.run INFO: Wating for event delivery
> [java]
> [java] TIME: 8:13:19 PM
> [java]
> [java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
> [java] EMSRIFT_PULL.run INFO: Verifying events
> [java] NonActGrp-out: ::verifyEvent() verifying
> [java] NonActGrp-out: Desired event was found:
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> [java] NonActGrp-out: Events
> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]]}
> [java] NonActGrp-out: ::verifyEvent() verifying
> [java] NonActGrp-out: Desired event was found:
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> [java] NonActGrp-out: Events
> are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
> =net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936
> ]]]]]}
> [java] NonActGrp-out: ::verifyEvent() verifying
> [java] NonActGrp-out: Desired event was found:
> com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
> [java] #
> [java] # A fatal error has been detected by the Java Runtime
> Environment:
> [java] #
> [java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling registration
> lease
> [java] (nmethod.cpp:1847), pid=6166, tid=3033299824
> [java] # Error: guarantee(cont_offset != 0,"unhandled implicit
> exception in compiled code")
> [java] #
> [java] # JRE version: 6.0_18-b18
> [java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
> linux-x86 )
> [java] # Derivative: IcedTea6 1.8.1
> [java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
> [java] # An error report file with more information is saved as:
> [java] # /home/pats/River/qa/hs_err_pid6166.log
> [java] EMSRIFT_PULL.run INFO: Generating 5 more events
> [java] #
> [java] # If you would like to submit a bug report, please include
> [java] # instructions how to reproduce the bug and visit:
> [java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
> [java] #
> [java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
> [java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
> [java]
> [java] TIME: 8:13:19 PM
> [java]
> [java] Test process was destroyed and returned code 134
> [java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
> [java] Test Failed: Test VM terminated without returning test status
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 9/22/2010 5:04 PM, Patricia Shanahan wrote:
> Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
> NullPointerException in
> com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
>
> A re-run of the qa.run test that first got the failure did not repeat
> it. I have started repeatedly running the one test, and got one more
> failure out of 568 runs, so far. I am continuing the repeated run to get
> a more statistically significant estimate of the failure rate.
>
> This is obviously going to be difficult to debug, or even to know if we
> have fixed it after a change. The bug may have existed for a long time.
I got the following failure on the trunk head revision, with SDM's
addProxyReg modified with a couple of Thread.sleep calls. Note that this
failure is one in thousands of runs, so don't count on reproducing it,
e.g. to get more logging data.
Any ideas what went wrong?
[java] Running com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Time is Wed Sep 22 20:13:06 PDT 2010
[java] Starting test in separate process with command:
[java] /usr/lib/jvm/java-6-openjdk/jre/bin/java
-Djava.security.policy=file:/home/pats/River/qa/harness/policy/defaulttest.policy
-cp
/home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar
-client
-Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
-Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=8081
-Dcom.sun.jini.jsk.home=/home/pats/River
-Dcom.sun.jini.qa.home=/home/pats/River/qa
-Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar
-Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar
-Dcom.sun.jini.qa.harness.runjiniserver=true
-Dcom.sun.jini.qa.harness.runkitserver=true
-Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties
-Dcom.sun.jini.qa.harness.testhosts=
-Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging
-Dcom.sun.jini.test.home=/home/pats/River/qa
-Dcom.sun.jini.test.port=8082
-Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy
-Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext
com.sun.jini.qa.harness.MasterTest
com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java]
[java] TIME: 8:13:06 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================== CALLING SETUP()
==============================
[java]
[java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
8081]
[java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/lib-dl/], port
8080]
[java] Sep 22, 2010 8:13:06 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/home/pats/River/qa/lib/], port
8082]
[java] MasterTest.doTest INFO:
[java] =============================== CALLING RUN()
===============================
[java]
[java] NonActGrp-out: Sep 22, 2010 8:13:08 PM
com.sun.jini.reggie.RegistrarImpl init
[java] NonActGrp-out: INFO: started Reggie:
3fd8480d-7e19-46fe-a3c9-c0cbd14c27da,
[LDSLookupServiceGroup_UbantuDesktop_1285211586313],
ConstrainableLookupLocator[[jini://UbantuDesktop/], [null]]
[java] NonActGrp-out: Sep 22, 2010 8:13:09 PM
com.sun.jini.mercury.MailboxImpl doInit
[java] NonActGrp-out: INFO: Mercury started:
com.sun.jini.mercury.TransientMercuryImpl@2b323e
[java] MailboxTestBase.getPullMailbox INFO: Got reference to
PullEventMailbox service:
com.sun.jini.mercury.MailboxProxy$ConstrainableMailboxProxy@759ce264
[java] MailboxTestBase.getPullRegistration INFO: Got reference to
MailboxPullRegistration object:
com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
[java] MailboxTestBase.getPullRegistration INFO: registration
proxy preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullRegistration INFO: Prepared
registration proxy:
com.sun.jini.mercury.Registration$ConstrainableRegistration@79347b94
[java] MailboxTestBase.getPullMailboxLease INFO: Calling
getPullMailboxLease()
[java] MailboxTestBase.getPullMailboxLease INFO: mailbox lease
preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullMailboxLease INFO: Prepared mailbox
lease proxy: LandlordLease:a82734db-3f86-4405-8e84-c90f6011c245
landlord:Proxy[MailboxBackEnd,BasicInvocationHandler[BasicObjectEndpoint[b12586dc-f39e-4d53-a9fd-5eed01e9f487,TcpEndpoint[127.0.1.1:55936]]]]
landlordUuid:106e433a-5c4c-4ccf-9dae-7812a4109583
com.sun.jini.landlord.ConstrainableLandlordLease@79347b94
[java] MailboxTestBase.checkLease INFO: Lease request for 180000
granted
[java] EMSRIFT_PULL.run INFO: Mailbox lease good untilWed Sep 22
20:16:09 PDT 2010
[java] MailboxTestBase.getPullMailboxListener INFO: Calling
getPullMailboxListener()
[java] MailboxTestBase.getPullMailboxListener INFO: mailbox
listener preparer: BasicProxyPreparer[]
[java] MailboxTestBase.getPullMailboxListener INFO: Prepared
mailbox listener proxy:
com.sun.jini.mercury.ListenerProxy$ConstrainableListenerProxy@79347b94
[java] MailboxTestBase.checkLease INFO: Lease request for 180000
granted
[java] MailboxTestUtils: createPullListeners: created 1
TestPullListener(s)
[java] EMSRIFT_PULL.run INFO: Generating 5 events
[java] EMSRIFT_PULL.run INFO: Wating for event delivery
[java]
[java] TIME: 8:13:19 PM
[java]
[java] EMSRIFT_PULL.run INFO: Verifying event delivery count of 5
[java] EMSRIFT_PULL.run INFO: Verifying events
[java] NonActGrp-out: ::verifyEvent() verifying
[java] NonActGrp-out: Desired event was found:
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3
[java] NonActGrp-out: Events
are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]]}
[java] NonActGrp-out: ::verifyEvent() verifying
[java] NonActGrp-out: Desired event was found:
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0
[java] NonActGrp-out: Events
are:{com.sun.jini.test.impl.mercury.RemoteEventHandle@4d6=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d7=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d0=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]],
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d3=net.jini.core.event.RemoteEvent[source=Proxy[TestGenerator,BasicInvocationHandler[BasicObjectEndpoint[fe322b99-d59e-424e-9e63-e3b68dc427f8,TcpEndpoint[127.0.1.1:55936]]]]]}
[java] NonActGrp-out: ::verifyEvent() verifying
[java] NonActGrp-out: Desired event was found:
com.sun.jini.test.impl.mercury.RemoteEventHandle@4d1
[java] #
[java] # A fatal error has been detected by the Java Runtime
Environment:
[java] #
[java] # Internal ErrorEMSRIFT_PULL.run INFO: Cancelling
registration lease
[java] (nmethod.cpp:1847), pid=6166, tid=3033299824
[java] # Error: guarantee(cont_offset != 0,"unhandled implicit
exception in compiled code")
[java] #
[java] # JRE version: 6.0_18-b18
[java] # Java VM: OpenJDK Client VM (16.0-b13 mixed mode, sharing
linux-x86 )
[java] # Derivative: IcedTea6 1.8.1
[java] # Distribution: Ubuntu 10.04 LTS, package 6b18-1.8.1-0ubuntu1
[java] # An error report file with more information is saved as:
[java] # /home/pats/River/qa/hs_err_pid6166.log
[java] EMSRIFT_PULL.run INFO: Generating 5 more events
[java] #
[java] # If you would like to submit a bug report, please include
[java] # instructions how to reproduce the bug and visit:
[java] # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
[java] #
[java] EMSRIFT_PULL.run INFO: Caught NoSuchObjectException - expected
[java] EMSRIFT_PULL.run INFO: Re-cancelling registration lease
[java]
[java] TIME: 8:13:19 PM
[java]
[java] Test process was destroyed and returned code 134
[java] com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
[java] Test Failed: Test VM terminated without returning test status
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I seem to have lost my ability to run tests successfully directly on
WindowsXP. Even a clean check-out of the trunk head, without my
experimental changes, gets errors.
Meanwhile, I ran some tests under Ubuntu, and one qa.run test got a
NullPointerException in com/sun/jini/test/spec/eventmailbox/EMSRIFT_PULL2.td
A re-run of the qa.run test that first got the failure did not repeat
it. I have started repeatedly running the one test, and got one more
failure out of 568 runs, so far. I am continuing the repeated run to get
a more statistically significant estimate of the failure rate.
This is obviously going to be difficult to debug, or even to know if we
have fixed it after a change. The bug may have existed for a long time.
Patricia
On 9/21/2010 2:33 PM, Patricia Shanahan wrote:
> I'm testing my new TaskManager the , but I have some anomalies. It would
> help me to get some more testing of
> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManager
> done in other WindowsXP environments.
>
> Both the head revision and revision 998737 need to be tested. Revision
> 998737 is the one I plan to merge into the trunk. It changes the
> interface between TaskManager and its callers, with minimal changes to
> TaskManager.
>
> It is important that it be tested widely, because it affects a lot of
> critical classes, and would be difficult to back out.
>
> The head revision drops in a revised TaskManager. It should be easy to
> back out if necessary.
>
> Patricia
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
Jonathan Costers wrote:
> The complete current QA test suite passed with this change included.
> Also, I ran the "txnmanager" category, all tests pass except GetStateTest.td
> (which hangs), but this one was already behaving that way without this fix.
>
> I'd say commit it.
I agree. Could you commit it for me? I don't have access to the computer
that I have set up for River work.
>
> PS: if anyone would be able to debug GetStateTest and figure out what is
> wrong with it, we could add another 40-something tests (covering mahalo impl
> and the transactionmanager spec) to our QA run on Hudson (txnmanager
> category).
If it is not fixed by the time I get back to River work in a couple of
weeks, I'll take a look at it.
I'm glad to see that there are transactionmanager spec tests that are
not being run. The failure that the patch fixes is so easy to test that
I was troubled by it not having been detected before. Maybe there is a
test that would report it that is not being run.
>
> 2010/9/27 Jonathan Costers <jo...@googlemail.com>
>
>> This fix actually made the test pass for me for the first time.
>> I'm running the complete suite against it (all the categories that are
>> executed on Hudson) now.
>>
>>
>> 2010/9/27 Tom Hobbs <tv...@googlemail.com>
>>
>> Good find!
>>>> There is an issue of whether there is anything else that depends on
>>> getting a RuntimeException rather than a
>>>> checked exception, so it needs a full regression test.
>>> If other tests rely on the incorrect behaviour of TxnManagerImpl then I'd
>>> say that the other tests are wrong by definition. If this change breaks
>>> other tests then those other tests need appropriate fixes. I'd check in
>>> the
>>> fix now, if the build starts breaking in new and exciting places then the
>>> cause of those breakages should be easy to diagnose.
>>>
>>>
>>> On Mon, Sep 27, 2010 at 11:18 AM, Patricia Shanahan <pa...@acm.org> wrote:
>>>
>>>> I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but
>>> may
>>>> not have time to regression test and check in the fix.
>>>>
>>>> The test failure is due to an error in
>>>> com/sun/jini/mahalo/TxnManagerImpl.java. It throws a
>>> NullPointerException
>>>> from abort if the transaction is not known to transaction management.
>>> That
>>>> case can arise, even for a formerly valid transaction, due to it having
>>>> already been committed or aborted, so it is timing dependent and more
>>> likely
>>>> to happen under stress than when doing more controlled tests.
>>>>
>>>> The TransactionManager interface specifies UnknownTransactionException
>>> for
>>>> that case. The test catches UnknownTransactionException and treats it as
>>> a
>>>> valid, non-error result. NullPointerException is not caught until it
>>> gets
>>>> back to the TaskManager's thread run method, which turns it into a
>>> logged
>>>> WARNING. The uncaught exception prevents the task from reporting
>>> completion
>>>> back to the test, leading to the timeout and test failure.
>>>>
>>>> There is an issue of whether there is anything else that depends on
>>> getting
>>>> a RuntimeException rather than a checked exception, so it needs a full
>>>> regression test.
>>>>
>>>> I also recommend reducing the timeout from 30 minutes. When the test
>>>> succeeds, it takes less than a minute.
>>>>
>>>> Here is a patch to change the exception:
>>>>
>>>> Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
>>>> ===================================================================
>>>> --- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
>>>> +++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
>>>> @@ -933,7 +933,7 @@
>>>> }
>>>>
>>>> } else {
>>>> - throw new NullPointerException("No such transaction
>>> ["+id+"]");
>>>> + throw new UnknownTransactionException("No such transaction
>>>> ["+id+"]");
>>>>
>>>> }
>>>>
>>>>
>>>> Patricia
>>>>
>>>>
>>>> On 9/25/2010 7:17 AM, Jonathan Costers wrote:
>>>>
>>>>> I actually did come across a test that may be interesting to run for
>>> these
>>>>> changes ...
>>>>>
>>>>> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>>>>>
>>>>> I have not been able to get this test to pass on any of my machines or
>>> VMs
>>>>> ...
>>>>> It seems to make heavy use of TaskManager and RetryTask.
>>>>> It can take a while to finish as well, so beware.
>>>>>
>>>>> You think this may be a good one?
>>>>>
>>>>> you can run it if you change to the<river>/qa directory and execute:
>>>>> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>>>>> run-tests
>>>>>
>>>>> or similarly in an IDE, set property
>>>>> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>>>>> and run the run-tests target
>>>>>
>>>>> make sure everything is built first, of course.
>>>>>
>>>>> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>>>>>
>>>>> I'm testing my new TaskManager the , but I have some anomalies. It
>>> would
>>>>>> help me to get some more testing of
>>>>>>
>>>>>>
>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdoneinother WindowsXP environments.
>>>>>> Both the head revision and revision 998737 need to be tested.
>>> Revision
>>>>>> 998737 is the one I plan to merge into the trunk. It changes the
>>>>>> interface
>>>>>> between TaskManager and its callers, with minimal changes to
>>> TaskManager.
>>>>>> It is important that it be tested widely, because it affects a lot of
>>>>>> critical classes, and would be difficult to back out.
>>>>>>
>>>>>> The head revision drops in a revised TaskManager. It should be easy to
>>>>>> back
>>>>>> out if necessary.
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>
>
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
That was my observation as well.
I think the txnmanager spec may shed some light?
The original Jini specs are included in the doc folder.
2010/10/14 Patricia Shanahan <pa...@acm.org>
> On 10/14/2010 12:55 PM, Patricia Shanahan wrote:
>
>> Jonathan Costers wrote:
>>
>>> The complete current QA test suite passed with this change included.
>>> Also, I ran the "txnmanager" category, all tests pass except
>>> GetStateTest.td
>>> (which hangs), but this one was already behaving that way without this
>>> fix.
>>>
>>> I'd say commit it.
>>>
>>> PS: if anyone would be able to debug GetStateTest and figure out what is
>>> wrong with it, we could add another 40-something tests (covering
>>> mahalo impl
>>> and the transactionmanager spec) to our QA run on Hudson (txnmanager
>>> category).
>>>
>>
>> I'm back from my vacation, and ready to resume River activities. I'll
>> take a look at GetStateTest.td, unless there is something more urgent.
>>
>
> I have a specification question. Is a TransactionManager *required* to
> forget a transaction within some amount of time after it has been aborted?
>
> The test hangs because it is waiting for getState to throw an exception,
> rather than going on reporting state 6, TransactionConstants.ABORTED.
>
> Patricia
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
On 10/14/2010 12:55 PM, Patricia Shanahan wrote:
> Jonathan Costers wrote:
>> The complete current QA test suite passed with this change included.
>> Also, I ran the "txnmanager" category, all tests pass except
>> GetStateTest.td
>> (which hangs), but this one was already behaving that way without this
>> fix.
>>
>> I'd say commit it.
>>
>> PS: if anyone would be able to debug GetStateTest and figure out what is
>> wrong with it, we could add another 40-something tests (covering
>> mahalo impl
>> and the transactionmanager spec) to our QA run on Hudson (txnmanager
>> category).
>
> I'm back from my vacation, and ready to resume River activities. I'll
> take a look at GetStateTest.td, unless there is something more urgent.
I have a specification question. Is a TransactionManager *required* to
forget a transaction within some amount of time after it has been aborted?
The test hangs because it is waiting for getState to throw an exception,
rather than going on reporting state 6, TransactionConstants.ABORTED.
Patricia
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
Jonathan Costers wrote:
> The complete current QA test suite passed with this change included.
> Also, I ran the "txnmanager" category, all tests pass except GetStateTest.td
> (which hangs), but this one was already behaving that way without this fix.
>
> I'd say commit it.
>
> PS: if anyone would be able to debug GetStateTest and figure out what is
> wrong with it, we could add another 40-something tests (covering mahalo impl
> and the transactionmanager spec) to our QA run on Hudson (txnmanager
> category).
I'm back from my vacation, and ready to resume River activities. I'll
take a look at GetStateTest.td, unless there is something more urgent.
Patricia
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
The complete current QA test suite passed with this change included.
Also, I ran the "txnmanager" category, all tests pass except GetStateTest.td
(which hangs), but this one was already behaving that way without this fix.
I'd say commit it.
PS: if anyone would be able to debug GetStateTest and figure out what is
wrong with it, we could add another 40-something tests (covering mahalo impl
and the transactionmanager spec) to our QA run on Hudson (txnmanager
category).
2010/9/27 Jonathan Costers <jo...@googlemail.com>
> This fix actually made the test pass for me for the first time.
> I'm running the complete suite against it (all the categories that are
> executed on Hudson) now.
>
>
> 2010/9/27 Tom Hobbs <tv...@googlemail.com>
>
> Good find!
>>
>> > There is an issue of whether there is anything else that depends on
>> getting a RuntimeException rather than a
>> > checked exception, so it needs a full regression test.
>>
>> If other tests rely on the incorrect behaviour of TxnManagerImpl then I'd
>> say that the other tests are wrong by definition. If this change breaks
>> other tests then those other tests need appropriate fixes. I'd check in
>> the
>> fix now, if the build starts breaking in new and exciting places then the
>> cause of those breakages should be easy to diagnose.
>>
>>
>> On Mon, Sep 27, 2010 at 11:18 AM, Patricia Shanahan <pa...@acm.org> wrote:
>>
>> > I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but
>> may
>> > not have time to regression test and check in the fix.
>> >
>> > The test failure is due to an error in
>> > com/sun/jini/mahalo/TxnManagerImpl.java. It throws a
>> NullPointerException
>> > from abort if the transaction is not known to transaction management.
>> That
>> > case can arise, even for a formerly valid transaction, due to it having
>> > already been committed or aborted, so it is timing dependent and more
>> likely
>> > to happen under stress than when doing more controlled tests.
>> >
>> > The TransactionManager interface specifies UnknownTransactionException
>> for
>> > that case. The test catches UnknownTransactionException and treats it as
>> a
>> > valid, non-error result. NullPointerException is not caught until it
>> gets
>> > back to the TaskManager's thread run method, which turns it into a
>> logged
>> > WARNING. The uncaught exception prevents the task from reporting
>> completion
>> > back to the test, leading to the timeout and test failure.
>> >
>> > There is an issue of whether there is anything else that depends on
>> getting
>> > a RuntimeException rather than a checked exception, so it needs a full
>> > regression test.
>> >
>> > I also recommend reducing the timeout from 30 minutes. When the test
>> > succeeds, it takes less than a minute.
>> >
>> > Here is a patch to change the exception:
>> >
>> > Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
>> > ===================================================================
>> > --- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
>> > +++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
>> > @@ -933,7 +933,7 @@
>> > }
>> >
>> > } else {
>> > - throw new NullPointerException("No such transaction
>> ["+id+"]");
>> > + throw new UnknownTransactionException("No such transaction
>> > ["+id+"]");
>> >
>> > }
>> >
>> >
>> > Patricia
>> >
>> >
>> > On 9/25/2010 7:17 AM, Jonathan Costers wrote:
>> >
>> >> I actually did come across a test that may be interesting to run for
>> these
>> >> changes ...
>> >>
>> >> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> >>
>> >> I have not been able to get this test to pass on any of my machines or
>> VMs
>> >> ...
>> >> It seems to make heavy use of TaskManager and RetryTask.
>> >> It can take a while to finish as well, so beware.
>> >>
>> >> You think this may be a good one?
>> >>
>> >> you can run it if you change to the<river>/qa directory and execute:
>> >> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> >> run-tests
>> >>
>> >> or similarly in an IDE, set property
>> >> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> >> and run the run-tests target
>> >>
>> >> make sure everything is built first, of course.
>> >>
>> >> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>> >>
>> >> I'm testing my new TaskManager the , but I have some anomalies. It
>> would
>> >>> help me to get some more testing of
>> >>>
>> >>>
>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdoneinother WindowsXP environments.
>> >>>
>> >>> Both the head revision and revision 998737 need to be tested.
>> Revision
>> >>> 998737 is the one I plan to merge into the trunk. It changes the
>> >>> interface
>> >>> between TaskManager and its callers, with minimal changes to
>> TaskManager.
>> >>>
>> >>> It is important that it be tested widely, because it affects a lot of
>> >>> critical classes, and would be difficult to back out.
>> >>>
>> >>> The head revision drops in a revised TaskManager. It should be easy to
>> >>> back
>> >>> out if necessary.
>> >>>
>> >>> Patricia
>> >>>
>> >>>
>> >>
>> >
>>
>
>
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
This fix actually made the test pass for me for the first time.
I'm running the complete suite against it (all the categories that are
executed on Hudson) now.
2010/9/27 Tom Hobbs <tv...@googlemail.com>
> Good find!
>
> > There is an issue of whether there is anything else that depends on
> getting a RuntimeException rather than a
> > checked exception, so it needs a full regression test.
>
> If other tests rely on the incorrect behaviour of TxnManagerImpl then I'd
> say that the other tests are wrong by definition. If this change breaks
> other tests then those other tests need appropriate fixes. I'd check in
> the
> fix now, if the build starts breaking in new and exciting places then the
> cause of those breakages should be easy to diagnose.
>
>
> On Mon, Sep 27, 2010 at 11:18 AM, Patricia Shanahan <pa...@acm.org> wrote:
>
> > I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but may
> > not have time to regression test and check in the fix.
> >
> > The test failure is due to an error in
> > com/sun/jini/mahalo/TxnManagerImpl.java. It throws a NullPointerException
> > from abort if the transaction is not known to transaction management.
> That
> > case can arise, even for a formerly valid transaction, due to it having
> > already been committed or aborted, so it is timing dependent and more
> likely
> > to happen under stress than when doing more controlled tests.
> >
> > The TransactionManager interface specifies UnknownTransactionException
> for
> > that case. The test catches UnknownTransactionException and treats it as
> a
> > valid, non-error result. NullPointerException is not caught until it gets
> > back to the TaskManager's thread run method, which turns it into a logged
> > WARNING. The uncaught exception prevents the task from reporting
> completion
> > back to the test, leading to the timeout and test failure.
> >
> > There is an issue of whether there is anything else that depends on
> getting
> > a RuntimeException rather than a checked exception, so it needs a full
> > regression test.
> >
> > I also recommend reducing the timeout from 30 minutes. When the test
> > succeeds, it takes less than a minute.
> >
> > Here is a patch to change the exception:
> >
> > Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
> > ===================================================================
> > --- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
> > +++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
> > @@ -933,7 +933,7 @@
> > }
> >
> > } else {
> > - throw new NullPointerException("No such transaction
> ["+id+"]");
> > + throw new UnknownTransactionException("No such transaction
> > ["+id+"]");
> >
> > }
> >
> >
> > Patricia
> >
> >
> > On 9/25/2010 7:17 AM, Jonathan Costers wrote:
> >
> >> I actually did come across a test that may be interesting to run for
> these
> >> changes ...
> >>
> >> com/sun/jini/test/impl/mahalo/RandomStressTest.td
> >>
> >> I have not been able to get this test to pass on any of my machines or
> VMs
> >> ...
> >> It seems to make heavy use of TaskManager and RetryTask.
> >> It can take a while to finish as well, so beware.
> >>
> >> You think this may be a good one?
> >>
> >> you can run it if you change to the<river>/qa directory and execute:
> >> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
> >> run-tests
> >>
> >> or similarly in an IDE, set property
> >> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
> >> and run the run-tests target
> >>
> >> make sure everything is built first, of course.
> >>
> >> 2010/9/21 Patricia Shanahan<pa...@acm.org>
> >>
> >> I'm testing my new TaskManager the , but I have some anomalies. It
> would
> >>> help me to get some more testing of
> >>>
> >>>
> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdoneinother WindowsXP environments.
> >>>
> >>> Both the head revision and revision 998737 need to be tested. Revision
> >>> 998737 is the one I plan to merge into the trunk. It changes the
> >>> interface
> >>> between TaskManager and its callers, with minimal changes to
> TaskManager.
> >>>
> >>> It is important that it be tested widely, because it affects a lot of
> >>> critical classes, and would be difficult to back out.
> >>>
> >>> The head revision drops in a revised TaskManager. It should be easy to
> >>> back
> >>> out if necessary.
> >>>
> >>> Patricia
> >>>
> >>>
> >>
> >
>
Re: Request for testing help
Posted by Tom Hobbs <tv...@googlemail.com>.
Good find!
> There is an issue of whether there is anything else that depends on
getting a RuntimeException rather than a
> checked exception, so it needs a full regression test.
If other tests rely on the incorrect behaviour of TxnManagerImpl then I'd
say that the other tests are wrong by definition. If this change breaks
other tests then those other tests need appropriate fixes. I'd check in the
fix now, if the build starts breaking in new and exciting places then the
cause of those breakages should be easy to diagnose.
On Mon, Sep 27, 2010 at 11:18 AM, Patricia Shanahan <pa...@acm.org> wrote:
> I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but may
> not have time to regression test and check in the fix.
>
> The test failure is due to an error in
> com/sun/jini/mahalo/TxnManagerImpl.java. It throws a NullPointerException
> from abort if the transaction is not known to transaction management. That
> case can arise, even for a formerly valid transaction, due to it having
> already been committed or aborted, so it is timing dependent and more likely
> to happen under stress than when doing more controlled tests.
>
> The TransactionManager interface specifies UnknownTransactionException for
> that case. The test catches UnknownTransactionException and treats it as a
> valid, non-error result. NullPointerException is not caught until it gets
> back to the TaskManager's thread run method, which turns it into a logged
> WARNING. The uncaught exception prevents the task from reporting completion
> back to the test, leading to the timeout and test failure.
>
> There is an issue of whether there is anything else that depends on getting
> a RuntimeException rather than a checked exception, so it needs a full
> regression test.
>
> I also recommend reducing the timeout from 30 minutes. When the test
> succeeds, it takes less than a minute.
>
> Here is a patch to change the exception:
>
> Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
> ===================================================================
> --- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
> +++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
> @@ -933,7 +933,7 @@
> }
>
> } else {
> - throw new NullPointerException("No such transaction ["+id+"]");
> + throw new UnknownTransactionException("No such transaction
> ["+id+"]");
>
> }
>
>
> Patricia
>
>
> On 9/25/2010 7:17 AM, Jonathan Costers wrote:
>
>> I actually did come across a test that may be interesting to run for these
>> changes ...
>>
>> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>>
>> I have not been able to get this test to pass on any of my machines or VMs
>> ...
>> It seems to make heavy use of TaskManager and RetryTask.
>> It can take a while to finish as well, so beware.
>>
>> You think this may be a good one?
>>
>> you can run it if you change to the<river>/qa directory and execute:
>> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> run-tests
>>
>> or similarly in an IDE, set property
>> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> and run the run-tests target
>>
>> make sure everything is built first, of course.
>>
>> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>>> help me to get some more testing of
>>>
>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdonein other WindowsXP environments.
>>>
>>> Both the head revision and revision 998737 need to be tested. Revision
>>> 998737 is the one I plan to merge into the trunk. It changes the
>>> interface
>>> between TaskManager and its callers, with minimal changes to TaskManager.
>>>
>>> It is important that it be tested widely, because it affects a lot of
>>> critical classes, and would be difficult to back out.
>>>
>>> The head revision drops in a revised TaskManager. It should be easy to
>>> back
>>> out if necessary.
>>>
>>> Patricia
>>>
>>>
>>
>
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
Hmmm... Great job!
Actually, I've come across a similar situation in a test in the txnmanager
category, where the test was waiting (in a loop) for an
UnknownTransactionException, but the interface specified throwing a
CannotCommitException instead. So the test hanged. I committed a fix for
that a little while ago.
Little strange if you ask me...
I will try out your fix tonight and post back the results.
2010/9/27 Patricia Shanahan <pa...@acm.org>
> I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but may
> not have time to regression test and check in the fix.
>
> The test failure is due to an error in
> com/sun/jini/mahalo/TxnManagerImpl.java. It throws a NullPointerException
> from abort if the transaction is not known to transaction management. That
> case can arise, even for a formerly valid transaction, due to it having
> already been committed or aborted, so it is timing dependent and more likely
> to happen under stress than when doing more controlled tests.
>
> The TransactionManager interface specifies UnknownTransactionException for
> that case. The test catches UnknownTransactionException and treats it as a
> valid, non-error result. NullPointerException is not caught until it gets
> back to the TaskManager's thread run method, which turns it into a logged
> WARNING. The uncaught exception prevents the task from reporting completion
> back to the test, leading to the timeout and test failure.
>
> There is an issue of whether there is anything else that depends on getting
> a RuntimeException rather than a checked exception, so it needs a full
> regression test.
>
> I also recommend reducing the timeout from 30 minutes. When the test
> succeeds, it takes less than a minute.
>
> Here is a patch to change the exception:
>
> Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
> ===================================================================
> --- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
> +++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
> @@ -933,7 +933,7 @@
> }
>
> } else {
> - throw new NullPointerException("No such transaction ["+id+"]");
> + throw new UnknownTransactionException("No such transaction
> ["+id+"]");
>
> }
>
>
> Patricia
>
>
> On 9/25/2010 7:17 AM, Jonathan Costers wrote:
>
>> I actually did come across a test that may be interesting to run for these
>> changes ...
>>
>> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>>
>> I have not been able to get this test to pass on any of my machines or VMs
>> ...
>> It seems to make heavy use of TaskManager and RetryTask.
>> It can take a while to finish as well, so beware.
>>
>> You think this may be a good one?
>>
>> you can run it if you change to the<river>/qa directory and execute:
>> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> run-tests
>>
>> or similarly in an IDE, set property
>> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
>> and run the run-tests target
>>
>> make sure everything is built first, of course.
>>
>> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>>> help me to get some more testing of
>>>
>>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdonein other WindowsXP environments.
>>>
>>>
>>> Both the head revision and revision 998737 need to be tested. Revision
>>> 998737 is the one I plan to merge into the trunk. It changes the
>>> interface
>>> between TaskManager and its callers, with minimal changes to TaskManager.
>>>
>>> It is important that it be tested widely, because it affects a lot of
>>> critical classes, and would be difficult to back out.
>>>
>>> The head revision drops in a revised TaskManager. It should be easy to
>>> back
>>> out if necessary.
>>>
>>> Patricia
>>>
>>>
>>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I've diagnosed com/sun/jini/test/impl/mahalo/RandomStressTest.td, but
may not have time to regression test and check in the fix.
The test failure is due to an error in
com/sun/jini/mahalo/TxnManagerImpl.java. It throws a
NullPointerException from abort if the transaction is not known to
transaction management. That case can arise, even for a formerly valid
transaction, due to it having already been committed or aborted, so it
is timing dependent and more likely to happen under stress than when
doing more controlled tests.
The TransactionManager interface specifies UnknownTransactionException
for that case. The test catches UnknownTransactionException and treats
it as a valid, non-error result. NullPointerException is not caught
until it gets back to the TaskManager's thread run method, which turns
it into a logged WARNING. The uncaught exception prevents the task from
reporting completion back to the test, leading to the timeout and test
failure.
There is an issue of whether there is anything else that depends on
getting a RuntimeException rather than a checked exception, so it needs
a full regression test.
I also recommend reducing the timeout from 30 minutes. When the test
succeeds, it takes less than a minute.
Here is a patch to change the exception:
Index: src/com/sun/jini/mahalo/TxnManagerImpl.java
===================================================================
--- src/com/sun/jini/mahalo/TxnManagerImpl.java (revision 1000286)
+++ src/com/sun/jini/mahalo/TxnManagerImpl.java (working copy)
@@ -933,7 +933,7 @@
}
} else {
- throw new NullPointerException("No such transaction ["+id+"]");
+ throw new UnknownTransactionException("No such transaction ["+id+"]");
}
Patricia
On 9/25/2010 7:17 AM, Jonathan Costers wrote:
> I actually did come across a test that may be interesting to run for these
> changes ...
>
> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>
> I have not been able to get this test to pass on any of my machines or VMs
> ...
> It seems to make heavy use of TaskManager and RetryTask.
> It can take a while to finish as well, so beware.
>
> You think this may be a good one?
>
> you can run it if you change to the<river>/qa directory and execute:
> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td run-tests
>
> or similarly in an IDE, set property
> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
> and run the run-tests target
>
> make sure everything is built first, of course.
>
> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>> help me to get some more testing of
>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>>
>> Both the head revision and revision 998737 need to be tested. Revision
>> 998737 is the one I plan to merge into the trunk. It changes the interface
>> between TaskManager and its callers, with minimal changes to TaskManager.
>>
>> It is important that it be tested widely, because it affects a lot of
>> critical classes, and would be difficult to back out.
>>
>> The head revision drops in a revised TaskManager. It should be easy to back
>> out if necessary.
>>
>> Patricia
>>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
I ran it with default logging and it failed, as expected. I've run it
three times with FINEST logging, and it passed every time. Presumably,
it really is bringing out some concurrency issue, and the extra logging
changes the timings enough to prevent the bug from happening.
Interesting.
Incidentally, it does not take long when it works, less than a minute.
When it fails, it spends most of its time doing 120 iterations of "Wait
about 15 sec." before reporting "Some of RandomStressTask tasks not yet
finished". When it passed, it only did one wait. Before really getting
into debug, I'm going to reduce the maximum number of waits to save time
when it fails.
Patricia
On 9/25/2010 7:17 AM, Jonathan Costers wrote:
> I actually did come across a test that may be interesting to run for these
> changes ...
>
> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>
> I have not been able to get this test to pass on any of my machines or VMs
> ...
> It seems to make heavy use of TaskManager and RetryTask.
> It can take a while to finish as well, so beware.
>
> You think this may be a good one?
>
> you can run it if you change to the<river>/qa directory and execute:
> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td run-tests
>
> or similarly in an IDE, set property
> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
> and run the run-tests target
>
> make sure everything is built first, of course.
>
> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>> help me to get some more testing of
>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>>
>> Both the head revision and revision 998737 need to be tested. Revision
>> 998737 is the one I plan to merge into the trunk. It changes the interface
>> between TaskManager and its callers, with minimal changes to TaskManager.
>>
>> It is important that it be tested widely, because it affects a lot of
>> critical classes, and would be difficult to back out.
>>
>> The head revision drops in a revised TaskManager. It should be easy to back
>> out if necessary.
>>
>> Patricia
>>
>
Re: Request for testing help
Posted by Patricia Shanahan <pa...@acm.org>.
Thanks. I'll investigate it as my next sub-project.
Patricia
On 9/25/2010 7:17 AM, Jonathan Costers wrote:
> I actually did come across a test that may be interesting to run for these
> changes ...
>
> com/sun/jini/test/impl/mahalo/RandomStressTest.td
>
> I have not been able to get this test to pass on any of my machines or VMs
> ...
> It seems to make heavy use of TaskManager and RetryTask.
> It can take a while to finish as well, so beware.
>
> You think this may be a good one?
>
> you can run it if you change to the<river>/qa directory and execute:
> ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td run-tests
>
> or similarly in an IDE, set property
> run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
> and run the run-tests target
>
> make sure everything is built first, of course.
>
> 2010/9/21 Patricia Shanahan<pa...@acm.org>
>
>> I'm testing my new TaskManager the , but I have some anomalies. It would
>> help me to get some more testing of
>> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>>
>> Both the head revision and revision 998737 need to be tested. Revision
>> 998737 is the one I plan to merge into the trunk. It changes the interface
>> between TaskManager and its callers, with minimal changes to TaskManager.
>>
>> It is important that it be tested widely, because it affects a lot of
>> critical classes, and would be difficult to back out.
>>
>> The head revision drops in a revised TaskManager. It should be easy to back
>> out if necessary.
>>
>> Patricia
>>
>
Re: Request for testing help
Posted by Jonathan Costers <jo...@googlemail.com>.
I actually did come across a test that may be interesting to run for these
changes ...
com/sun/jini/test/impl/mahalo/RandomStressTest.td
I have not been able to get this test to pass on any of my machines or VMs
...
It seems to make heavy use of TaskManager and RetryTask.
It can take a while to finish as well, so beware.
You think this may be a good one?
you can run it if you change to the <river>/qa directory and execute:
ant -Drun.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td run-tests
or similarly in an IDE, set property
run.tests=com/sun/jini/test/impl/mahalo/RandomStressTest.td
and run the run-tests target
make sure everything is built first, of course.
2010/9/21 Patricia Shanahan <pa...@acm.org>
> I'm testing my new TaskManager the , but I have some anomalies. It would
> help me to get some more testing of
> https://svn.apache.org/repos/asf/incubator/river/jtsk/skunk/patsTaskManagerdone in other WindowsXP environments.
>
> Both the head revision and revision 998737 need to be tested. Revision
> 998737 is the one I plan to merge into the trunk. It changes the interface
> between TaskManager and its callers, with minimal changes to TaskManager.
>
> It is important that it be tested widely, because it affects a lot of
> critical classes, and would be difficult to back out.
>
> The head revision drops in a revised TaskManager. It should be easy to back
> out if necessary.
>
> Patricia
>