You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2014/08/13 21:26:12 UTC
[jira] [Updated] (DERBY-6704) Hang in
AutoloadTest.spawnProcess:JDBCDriversEmbeddedTest on Mac/jdk7,8
[ https://issues.apache.org/jira/browse/DERBY-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-6704:
---------------------------------
Description:
In our release tests for 10.11 we have seen this stack trace:
{code}
org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess:JDBCDriversEmbeddedTest 2701.548 s
junit.framework.AssertionFailedError: Test process failed:Spawned org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversEmbeddedTest exitCode=143
STDOUT:
..
at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess(AutoloadTest.java:256)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
{code}
presumably because the spawned process is killed by the test framework; it had been executing for 2701 second, but we don't have much insight into what happened to the subprocess because we don't collect its std our or std err.
was:
In our release tests for 10.11 we have seen this stack trace:
{code}
org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess:JDBCDriversEmbeddedTest 2701.548 s
junit.framework.AssertionFailedError: Test process failed:Spawned org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversEmbeddedTest exitCode=143
STDOUT:
..
at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess(AutoloadTest.java:256)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
{code}
presumably because the spawned process is killed by the test framework; it had been executing for 2701 second, but we don't have much insight into what happened to the subprocess because we don't collect its std our or std err.
> Hang in AutoloadTest.spawnProcess:JDBCDriversEmbeddedTest on Mac/jdk7,8
> -----------------------------------------------------------------------
>
> Key: DERBY-6704
> URL: https://issues.apache.org/jira/browse/DERBY-6704
> Project: Derby
> Issue Type: Bug
> Reporter: Dag H. Wanvik
>
> In our release tests for 10.11 we have seen this stack trace:
> {code}
> org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess:JDBCDriversEmbeddedTest 2701.548 s
> junit.framework.AssertionFailedError: Test process failed:Spawned org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCDriversEmbeddedTest exitCode=143
> STDOUT:
> ..
> at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadTest.spawnProcess(AutoloadTest.java:256)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:118)
> at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:440)
> at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:457)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> {code}
> presumably because the spawned process is killed by the test framework; it had been executing for 2701 second, but we don't have much insight into what happened to the subprocess because we don't collect its std our or std err.
--
This message was sent by Atlassian JIRA
(v6.2#6252)