Derby
  1. Derby
  2. DERBY-4111

ASSERT FAILED No page at pagenumber: 9; ContainerHandle = BaseContainerHandle:(Container(0, 1393))

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 10.4.1.3
    • Fix Version/s: None
    • Component/s: Store
    • Labels:
      None
    • Urgency:
      Normal
    • Bug behavior facts:
      Data corruption

      Description

      A user is seeing an error like this when using the application client-server. The client just sees they have been disconnected and no further queries work. The server sees the following stack trace:

      org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED No page at pagenumber: 9; ContainerHandle =
      BaseContainerHandle:(Container(0, 1393))
      at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
      at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
      at org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:838)
      at org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820)
      at org.apache.derby.impl.store.access.btree.BranchControlRow.getChildPageAtSlot(BranchControlRow.java:1423)
      at org.apache.derby.impl.store.access.btree.BranchControlRow.search(BranchControlRow.java:284)
      at org.apache.derby.impl.store.access.btree.BTreeController.doIns(BTreeController.java:634)
      at org.apache.derby.impl.store.access.btree.BTreeController.insert(BTreeController.java:1264)
      at org.apache.derby.impl.store.access.btree.index.B2IController.insert(B2IController.java:210)
      at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(IndexChanger.java:439)
      at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(IndexChanger.java:383)
      at org.apache.derby.impl.sql.execute.IndexChanger.insert(IndexChanger.java:589)
      at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(IndexSetChanger.java:268)
      at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(RowChangerImpl.java:453)
      at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1011)
      at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:487)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:372)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1307)
      at org.apache.derby.impl.drda.DRDAStatement.execute(DRDAStatement.java:672)
      at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(DRDAConnThread.java:4197)
      at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:4001)
      at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:991)
      at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:278)

      At first glance this appears to be identical to DERBY-3487 but apparently it's a new issue.

      It would be good to know if any corruption has occurred or if the assertion has avoided that happening.

        Activity

        Hide
        Trejkaz added a comment - - edited

        More information:

        • The database was originally created under Derby 10.2 or possibly 10.1. The tables have been migrated but the Derby store itself would still be the original format.
        • Other inserts into the same table work fine until a BLOB from some other table has been copied out. There is nothing about this other BLOB or its associated query in the logs so it seemingly completes successfully.
          This might be a red herring because the table in which we are inserting when the error occurs is indexed on the column which indicates what kind of event it was. So maybe it always happens when it's the same event type. This is yet to be confirmed.
        • Accessing the database directly with the embedded driver seems to dodge the problem (very interesting.)
        Show
        Trejkaz added a comment - - edited More information: The database was originally created under Derby 10.2 or possibly 10.1. The tables have been migrated but the Derby store itself would still be the original format. Other inserts into the same table work fine until a BLOB from some other table has been copied out. There is nothing about this other BLOB or its associated query in the logs so it seemingly completes successfully. This might be a red herring because the table in which we are inserting when the error occurs is indexed on the column which indicates what kind of event it was. So maybe it always happens when it's the same event type. This is yet to be confirmed. Accessing the database directly with the embedded driver seems to dodge the problem (very interesting.)
        Hide
        Mike Matrigali added a comment -

        Without a repro or the db, not much can be done on this issue.

        Usually when this kind of assert is reached, the damage is already done, the ASSERT does
        not avoid it. The stack indicates the problem is in an index, so the easiest thing to do is
        to identify the bad index and drop and recreate it. Use the consistency checker to do this:

        SYSCS_UTIL.SYSCS_CHECK_TABLE
        http://db.apache.org/derby/docs/dev/ref/rrefsyscschecktablefunc.html

        Show
        Mike Matrigali added a comment - Without a repro or the db, not much can be done on this issue. Usually when this kind of assert is reached, the damage is already done, the ASSERT does not avoid it. The stack indicates the problem is in an index, so the easiest thing to do is to identify the bad index and drop and recreate it. Use the consistency checker to do this: SYSCS_UTIL.SYSCS_CHECK_TABLE http://db.apache.org/derby/docs/dev/ref/rrefsyscschecktablefunc.html
        Hide
        Rick Hillegas added a comment -

        Triaged July 2, 2009: Marked as DataCorruption and assigned normal urgency.

        Show
        Rick Hillegas added a comment - Triaged July 2, 2009: Marked as DataCorruption and assigned normal urgency.
        Hide
        Rick Hillegas added a comment -

        Is there any more information on this issue? There is no repro or db, as Mike requested, so there is very little to go on. I am inclined to resolve this issue as "Cannot reproduce" unless more information surfaces. Thanks.

        Show
        Rick Hillegas added a comment - Is there any more information on this issue? There is no repro or db, as Mike requested, so there is very little to go on. I am inclined to resolve this issue as "Cannot reproduce" unless more information surfaces. Thanks.
        Hide
        Rick Hillegas added a comment -

        Closing this issue because it cannot be reproduced.

        Show
        Rick Hillegas added a comment - Closing this issue because it cannot be reproduced.

          People

          • Assignee:
            Unassigned
            Reporter:
            Trejkaz
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development