Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-5532

Failure in XplainStatisticsTest.testSimpleQueryMultiWithInvalidation: ERROR XSAI2: The conglomerate (-4,294,965,312) requested does not exist.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 10.8.3.0
    • Fix Version/s: None
    • Component/s: Store
    • Urgency:
      Normal
    • Bug behavior facts:
      Regression Test Failure

      Description

      Seen in the nightly testing of the 10.8 branch.
      http://dbtg.foundry.sun.com/derby/test/10.8Branch/jvm1.6/testing/testlog/lin/1213027-suitesAll_diff.txt

      1) testSimpleQueryMultiWithInvalidation(org.apache.derbyTesting.functionTests.tests.lang.XplainStatisticsTest)junit.framework.AssertionFailedError: select-thread failed
      at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:813)
      at org.apache.derbyTesting.functionTests.tests.lang.XplainStatisticsTest.testSimpleQueryMultiWithInvalidation(XplainStatisticsTest.java:876)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
      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)
      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)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      Caused by: java.sql.SQLException: The conglomerate (-4,294,965,312) requested does not exist.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown Source)
      at org.apache.derbyTesting.functionTests.tests.lang.XplainStatisticsTest$MTSimpleSelect.run(XplainStatisticsTest.java:2660)
      at java.lang.Thread.run(Thread.java:662)
      Caused by: java.sql.SQLException: The conglomerate (-4,294,965,312) requested does not exist.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
      ... 11 more
      Caused by: ERROR XSAI2: The conglomerate (-4,294,965,312) requested does not exist.
      at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
      at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(Unknown Source)
      at org.apache.derby.impl.sql.compile.FromList.bindTables(Unknown Source)
      at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(Unknown Source)
      at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(Unknown Source)
      at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source)
      at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
      at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.rePrepare(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
      ... 5 more

        Issue Links

          Activity

          Hide
          knutanders Knut Anders Hatlen added a comment -

          I agree that this is likely caused by DERBY-5358. I don't think the failure has been seen again, so I'm closing the bug as Cannot Reproduce.

          Show
          knutanders Knut Anders Hatlen added a comment - I agree that this is likely caused by DERBY-5358 . I don't think the failure has been seen again, so I'm closing the bug as Cannot Reproduce.
          Hide
          mikem Mike Matrigali added a comment -

          may be related to timing issue found in DERBY-5358

          Show
          mikem Mike Matrigali added a comment - may be related to timing issue found in DERBY-5358
          Hide
          mikem Mike Matrigali added a comment -

          derby triage 10.9. So far only one report. There have been a few reports that I have seen of various failures with
          bad conglomerate with a very large negative number. This has the feel of some timing corruption in the query plan
          overwriting the conglomerate number rather than the actual conglomerate number being bad.

          Conglomerate numbers for real tables should always be positive. Conglomerate numbers for temporary tables are negative
          but at least in our tests so far are never correctly going to get to -4,294,965,312 - so I don't think it is an overflow error.

          Show
          mikem Mike Matrigali added a comment - derby triage 10.9. So far only one report. There have been a few reports that I have seen of various failures with bad conglomerate with a very large negative number. This has the feel of some timing corruption in the query plan overwriting the conglomerate number rather than the actual conglomerate number being bad. Conglomerate numbers for real tables should always be positive. Conglomerate numbers for temporary tables are negative but at least in our tests so far are never correctly going to get to -4,294,965,312 - so I don't think it is an overflow error.

            People

            • Assignee:
              Unassigned
              Reporter:
              knutanders Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development