Derby
  1. Derby
  2. DERBY-4923

update of a long row can fail with ERROR nospc: nospc.U exception.

    Details

    • Urgency:
      Urgent
    • Issue & fix info:
      High Value Fix, Patch Available, Repro attached
    • Bug behavior facts:
      Data corruption

      Description

      An update of a row fails with a nospc.U exception. If there is space on the disk then an update should never fail for a space
      issue. The code is meant to always reserve enough space on a page such that if an expanding update happens that does not
      fit, it should in the worst case change the row to an overflow row pointer and put the rest in a linked overflow chain.

      The following set of circumstances will cause this bug (not sure which are exactly needed - just what i did to
      cause the repro), I will be attaching a test case:
      The row being updated has the following characteristics:
      o located on 4k page
      o 2 colum row with 2nd column a blob column
      o the row is a long row with first piece having 1st column on main page, and the 2nd piece having just blob column on overflow page.
      o before the update there is 0 free space on the overflow page.
      o the update causes the blob column to expand past 4k

      Caused by: java.sql.SQLException: nospc.U
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
      ... 39 more
      Caused by: ERROR nospc: nospc.U
      at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:4155)
      at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255)
      at org.apache.derby.impl.store.raw.data.UpdateOperation.<init>(UpdateOperation.java:106)
      at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80)
      at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8625)
      at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:1062)
      at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:486)
      at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:569)
      at org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:264)
      at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1241)
      ... 33 more

      1. derby4923repro.diff
        12 kB
        Mike Matrigali
      2. derby.log
        36 kB
        Mike Matrigali
      3. DERBY_4923.java
        7 kB
        Rick Hillegas
      4. derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff
        11 kB
        Rick Hillegas
      5. DERBY-4923.diff
        14 kB
        Mike Matrigali

        Issue Links

          Activity

          Myrna van Lunteren made changes -
          Fix Version/s 10.10.2.0 [ 12326659 ]
          Fix Version/s 10.10.1.4 [ 12324247 ]
          Mike Matrigali made changes -
          Link This issue relates to DERBY-6319 [ DERBY-6319 ]
          Mike Matrigali made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Mike Matrigali made changes -
          Fix Version/s 10.8.3.1 [ 12323475 ]
          Fix Version/s 10.9.2.2 [ 12323562 ]
          Fix Version/s 10.10.1.3 [ 12324247 ]
          Fix Version/s 10.11.0.0 [ 12324243 ]
          Hide
          Mike Matrigali added a comment -

          fixed in trunk and backported to 10.10, 10.9, and 10.8. I don't plan on backporting farther at this time, but it would be fine if someone else is interested.

          Show
          Mike Matrigali added a comment - fixed in trunk and backported to 10.10, 10.9, and 10.8. I don't plan on backporting farther at this time, but it would be fine if someone else is interested.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535577 from mikem@apache.org in branch 'code/branches/10.9'
          [ https://svn.apache.org/r1535577 ]

          DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception.

          backport change #1535413 from trunk to 10.9 branch.

          This checkin fixes the problem repro'd by the included new test, which shows
          an update of an existing row in db failing with a nosp.U exception.
          The problem was an off by 1 error in checking for enough space to update a row
          on an overflow page to just an overflow pointer. The intent of the code is to
          always reserve enough space in every overflow row to allow for this update.
          In this case there was exactly enough space, but the code mistaken thought it
          needed 1 more byte.

          Show
          ASF subversion and git services added a comment - Commit 1535577 from mikem@apache.org in branch 'code/branches/10.9' [ https://svn.apache.org/r1535577 ] DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception. backport change #1535413 from trunk to 10.9 branch. This checkin fixes the problem repro'd by the included new test, which shows an update of an existing row in db failing with a nosp.U exception. The problem was an off by 1 error in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535576 from mikem@apache.org in branch 'code/branches/10.8'
          [ https://svn.apache.org/r1535576 ]

          DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception.

          backport change #1535413 from trunk to 10.8 branch.

          This checkin fixes the problem repro'd by the included new test, which shows
          an update of an existing row in db failing with a nosp.U exception.
          The problem was an off by 1 error in checking for enough space to update a row
          on an overflow page to just an overflow pointer. The intent of the code is to
          always reserve enough space in every overflow row to allow for this update.
          In this case there was exactly enough space, but the code mistaken thought it
          needed 1 more byte.

          Show
          ASF subversion and git services added a comment - Commit 1535576 from mikem@apache.org in branch 'code/branches/10.8' [ https://svn.apache.org/r1535576 ] DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception. backport change #1535413 from trunk to 10.8 branch. This checkin fixes the problem repro'd by the included new test, which shows an update of an existing row in db failing with a nosp.U exception. The problem was an off by 1 error in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535523 from mikem@apache.org in branch 'code/branches/10.10'
          [ https://svn.apache.org/r1535523 ]

          DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception.

          backport change #1535413 from trunk to 10.10 branch.

          This checkin fixes the problem repro'd by the included new test, which shows
          an update of an existing row in db failing with a nosp.U exception.
          The problem was an off by 1 error in checking for enough space to update a row
          on an overflow page to just an overflow pointer. The intent of the code is to
          always reserve enough space in every overflow row to allow for this update.
          In this case there was exactly enough space, but the code mistaken thought it
          needed 1 more byte.

          Show
          ASF subversion and git services added a comment - Commit 1535523 from mikem@apache.org in branch 'code/branches/10.10' [ https://svn.apache.org/r1535523 ] DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception. backport change #1535413 from trunk to 10.10 branch. This checkin fixes the problem repro'd by the included new test, which shows an update of an existing row in db failing with a nosp.U exception. The problem was an off by 1 error in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535413 from mikem@apache.org in branch 'code/trunk'
          [ https://svn.apache.org/r1535413 ]

          DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception.

          This checkin fixes the problem repro'd by the included new test, which shows
          an update of an existing row in db failing with a nosp.U exception.
          The problem was an off by 1 error in checking for enough space to update a row
          on an overflow page to just an overflow pointer. The intent of the code is to
          always reserve enough space in every overflow row to allow for this update.
          In this case there was exactly enough space, but the code mistaken thought it
          needed 1 more byte.

          Show
          ASF subversion and git services added a comment - Commit 1535413 from mikem@apache.org in branch 'code/trunk' [ https://svn.apache.org/r1535413 ] DERBY-4923 update of a long row can fail with ERROR nospc: nospc.U exception. This checkin fixes the problem repro'd by the included new test, which shows an update of an existing row in db failing with a nosp.U exception. The problem was an off by 1 error in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535408 from mikem@apache.org in branch 'code/branches/10.8'
          [ https://svn.apache.org/r1535408 ]

          DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user

          backported change #1535206 from 10.10 to 10.8 branch, merge was clean.

          This patch adds the ability to dump a page in an insane build, and adds 2 calls
          to do so in 2 outstanding nospc error cases. In those two cases a new user
          level error is thrown and nests the nospc.U error so that we still know the
          original stack trace where the lowest error was thrown.
          The patch passes all tests and the specific errors were hand tested, one of
          them using the test case filed in DERBY-4923 and in the other case just by hand
          forcing the codepath.

          Show
          ASF subversion and git services added a comment - Commit 1535408 from mikem@apache.org in branch 'code/branches/10.8' [ https://svn.apache.org/r1535408 ] DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user backported change #1535206 from 10.10 to 10.8 branch, merge was clean. This patch adds the ability to dump a page in an insane build, and adds 2 calls to do so in 2 outstanding nospc error cases. In those two cases a new user level error is thrown and nests the nospc.U error so that we still know the original stack trace where the lowest error was thrown. The patch passes all tests and the specific errors were hand tested, one of them using the test case filed in DERBY-4923 and in the other case just by hand forcing the codepath.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535273 from mikem@apache.org in branch 'code/branches/10.9'
          [ https://svn.apache.org/r1535273 ]

          DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user

          backported change #1535206 from 10.10 to 10.9 branch, merge was clean.

          This patch adds the ability to dump a page in an insane build, and adds 2 calls
          to do so in 2 outstanding nospc error cases. In those two cases a new user
          level error is thrown and nests the nospc.U error so that we still know the
          original stack trace where the lowest error was thrown.
          The patch passes all tests and the specific errors were hand tested, one of
          them using the test case filed in DERBY-4923 and in the other case just by hand
          forcing the codepath.

          Show
          ASF subversion and git services added a comment - Commit 1535273 from mikem@apache.org in branch 'code/branches/10.9' [ https://svn.apache.org/r1535273 ] DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user backported change #1535206 from 10.10 to 10.9 branch, merge was clean. This patch adds the ability to dump a page in an insane build, and adds 2 calls to do so in 2 outstanding nospc error cases. In those two cases a new user level error is thrown and nests the nospc.U error so that we still know the original stack trace where the lowest error was thrown. The patch passes all tests and the specific errors were hand tested, one of them using the test case filed in DERBY-4923 and in the other case just by hand forcing the codepath.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535206 from mikem@apache.org in branch 'code/branches/10.10'
          [ https://svn.apache.org/r1535206 ]

          DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user

          backported change #1535075 from trunk to 10.10 branch, muliple manual changes
          were necessary for the backport.

          The backport of this change from trunk to 10.10 did not go cleanly at all due
          to usage of new java language features in messages in trunk. Here is the patch
          for 10.10 which I assume will backport cleanly to previous releases.
          The 2 problems were a new 15 param message and that trunk did not require
          Objects in newException() anymore. Also had to hand resolve a merge issue in
          StoredPage.java

          This patch adds the ability to dump a page in an insane build, and adds 2 calls
          to do so in 2 outstanding nospc error cases. In those two cases a new user
          level error is thrown and nests the nospc.U error so that we still know the
          original stack trace where the lowest error was thrown.
          The patch passes all tests and the specific errors were hand tested, one of
          them using the test case filed in DERBY-4923 and in the other case just by hand
          forcing the codepath.

          Show
          ASF subversion and git services added a comment - Commit 1535206 from mikem@apache.org in branch 'code/branches/10.10' [ https://svn.apache.org/r1535206 ] DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user backported change #1535075 from trunk to 10.10 branch, muliple manual changes were necessary for the backport. The backport of this change from trunk to 10.10 did not go cleanly at all due to usage of new java language features in messages in trunk. Here is the patch for 10.10 which I assume will backport cleanly to previous releases. The 2 problems were a new 15 param message and that trunk did not require Objects in newException() anymore. Also had to hand resolve a merge issue in StoredPage.java This patch adds the ability to dump a page in an insane build, and adds 2 calls to do so in 2 outstanding nospc error cases. In those two cases a new user level error is thrown and nests the nospc.U error so that we still know the original stack trace where the lowest error was thrown. The patch passes all tests and the specific errors were hand tested, one of them using the test case filed in DERBY-4923 and in the other case just by hand forcing the codepath.
          Hide
          ASF subversion and git services added a comment -

          Commit 1535075 from mikem@apache.org in branch 'code/trunk'
          [ https://svn.apache.org/r1535075 ]

          DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user
          This patch adds the ability to dump a page in an insane build, and adds 2 calls to do so in 2 outstanding nospc error cases. In those two cases a new user
          level error is thrown and nests the nospc.U error so that we still know the
          original stack trace where the lowest error was thrown.
          The patch passes all tests and the specific errors were hand tested, one of
          them using the test case filed in DERBY-4923 and in the other case just by hand forcing the codepath.

          Show
          ASF subversion and git services added a comment - Commit 1535075 from mikem@apache.org in branch 'code/trunk' [ https://svn.apache.org/r1535075 ] DERBY-6320 Log a page dump to derby.log if ERROR nospc: nospc.U is returned to the user This patch adds the ability to dump a page in an insane build, and adds 2 calls to do so in 2 outstanding nospc error cases. In those two cases a new user level error is thrown and nests the nospc.U error so that we still know the original stack trace where the lowest error was thrown. The patch passes all tests and the specific errors were hand tested, one of them using the test case filed in DERBY-4923 and in the other case just by hand forcing the codepath.
          Mike Matrigali made changes -
          Affects Version/s 10.10.1.1 [ 12321550 ]
          Affects Version/s 10.11.0.0 [ 12324243 ]
          Issue & fix info High Value Fix,Repro attached [ 10422, 10424 ] High Value Fix,Patch Available,Repro attached [ 10422, 10102, 10424 ]
          Mike Matrigali made changes -
          Attachment DERBY-4923.diff [ 12609878 ]
          Hide
          Mike Matrigali added a comment -

          This patch fixes the problem repro'd by the included new test. The problem was an off by 1 in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte.

          This patch also has been run full tests and passed against trunk.

          Show
          Mike Matrigali added a comment - This patch fixes the problem repro'd by the included new test. The problem was an off by 1 in checking for enough space to update a row on an overflow page to just an overflow pointer. The intent of the code is to always reserve enough space in every overflow row to allow for this update. In this case there was exactly enough space, but the code mistaken thought it needed 1 more byte. This patch also has been run full tests and passed against trunk.
          Mike Matrigali made changes -
          Assignee Mike Matrigali [ mikem ]
          Gavin made changes -
          Workflow jira [ 12538625 ] Default workflow, editable Closed status [ 12802578 ]
          Kathey Marsden made changes -
          Labels derby_triage10_10 derby_triage10_8 derby_triage10_11
          Kathey Marsden made changes -
          Labels derby_triage10_8 derby_triage10_10 derby_triage10_8
          Hide
          Kathey Marsden added a comment -

          Verified the repro attached still reproduces the error against trunk and . The reproduction connects with an in-memory database so I didn't verify but presumably the original Data corruption flag is correct as well. This would be great to get this one fixed for the next release. Do we have an idea of the scope of the work?

          Show
          Kathey Marsden added a comment - Verified the repro attached still reproduces the error against trunk and . The reproduction connects with an in-memory database so I didn't verify but presumably the original Data corruption flag is correct as well. This would be great to get this one fixed for the next release. Do we have an idea of the scope of the work?
          Rick Hillegas made changes -
          Link This issue is related to DERBY-5876 [ DERBY-5876 ]
          Hide
          Rick Hillegas added a comment -

          Thanks for that explanation, Mike. This observation particularly struck me:

          "So at least in the cases that I have debugged in the past the bug is not in the operation that is failing, it is in a previous operation that lead to the page getting to state with not enough reserved space to do the operation."

          This increases my suspicion that the attached repro may turn out to be another bug in table compression.

          On the related issue DERBY-5858, table compression was not used. So there is at least another code path, not involving table compression, which sets up this NoSpaceOnPage condition.

          Show
          Rick Hillegas added a comment - Thanks for that explanation, Mike. This observation particularly struck me: "So at least in the cases that I have debugged in the past the bug is not in the operation that is failing, it is in a previous operation that lead to the page getting to state with not enough reserved space to do the operation." This increases my suspicion that the attached repro may turn out to be another bug in table compression. On the related issue DERBY-5858 , table compression was not used. So there is at least another code path, not involving table compression, which sets up this NoSpaceOnPage condition.
          Hide
          Mike Matrigali added a comment -

          I do believe it is always a bug if a NoSpaceOnPage leaks out to a user. There is a normal case where we can't insert and/or update keys in indexes over a certain size, but I think that
          gets wrapped in a different exception.

          If the code were acting correctly then it would have reserved enough space such that the operation is not leaking the exception. So at least in the cases that I have debugged in the
          past the bug is not in the operation that is failing, it is in a previous operation that lead to the page getting to state with not enough reserved space to do the operation. There are
          2 things to handle. First is that the head of a row in a base table (heap) can never move off its page, so you must reserve enough space in the head row/page so that in the worst
          case you can change the row to one that just has the head of row pointing to a linked list of all the other columns on another page. The second case is handling the "middle" of the
          row on another page. Again similarly the design is to reserve enough space for the row such that if you need to expand it there is always enough space in worst case to just make
          it a pointer yet another chunk somewhere. It gets tricky in that a row might be smaller than what is necessary in the worst case to be one of these pointers.

          The mostly likely place for this bug to happen would be in UpdateOperation and UpdateFieldOperation as these result in expanding the length of the row in place.

          CopyRowsOperation prechecks that the destination of the rows has space and maintains a latch so that it is guaranteed. I remember a NoSpaceOnPage bug in the past in this one
          where the bug was in the check not accounting for the correct change in compressed size of the page field, so in this case the bug was in the operation and not in the previous operaition.

          InsertOperation is the normal path for NoSpaceOnPage exceptions, I expect that somehow the code is set to catch these as it is the normal way to tell to insert a row somewhere else
          rather than where it does not fit.

          Show
          Mike Matrigali added a comment - I do believe it is always a bug if a NoSpaceOnPage leaks out to a user. There is a normal case where we can't insert and/or update keys in indexes over a certain size, but I think that gets wrapped in a different exception. If the code were acting correctly then it would have reserved enough space such that the operation is not leaking the exception. So at least in the cases that I have debugged in the past the bug is not in the operation that is failing, it is in a previous operation that lead to the page getting to state with not enough reserved space to do the operation. There are 2 things to handle. First is that the head of a row in a base table (heap) can never move off its page, so you must reserve enough space in the head row/page so that in the worst case you can change the row to one that just has the head of row pointing to a linked list of all the other columns on another page. The second case is handling the "middle" of the row on another page. Again similarly the design is to reserve enough space for the row such that if you need to expand it there is always enough space in worst case to just make it a pointer yet another chunk somewhere. It gets tricky in that a row might be smaller than what is necessary in the worst case to be one of these pointers. The mostly likely place for this bug to happen would be in UpdateOperation and UpdateFieldOperation as these result in expanding the length of the row in place. CopyRowsOperation prechecks that the destination of the rows has space and maintains a latch so that it is guaranteed. I remember a NoSpaceOnPage bug in the past in this one where the bug was in the check not accounting for the correct change in compressed size of the page field, so in this case the bug was in the operation and not in the previous operaition. InsertOperation is the normal path for NoSpaceOnPage exceptions, I expect that somehow the code is set to catch these as it is the normal way to tell to insert a row somewhere else rather than where it does not fit.
          Rick Hillegas made changes -
          Hide
          Rick Hillegas added a comment -

          Comments on DERBY-4577 and DERBY-4923 suggest that NoSpaceOnPage is a transient signal passed between methods inside StoredPage. If you grep the codeline, you see that StoredPage is the only class which mentions this exception. Low level logging methods throw NoSpaceOnPage to tell their callers that there isn't enough room on the page for the operation. The callers (in StoredPage) are supposed to allocate more space and then retry the operation. It seems that NoSpaceOnPage should never leak out of StoredPage. It should never escape to methods higher on the call stack. Does that sound correct?

          I am attaching derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff. This patch changes NoSpaceOnPage, making it directly extend Exception so that it is no longer a StandardException. With this change you can see that it may be possible for NoSpaceOnPage to escape outside StoredPage to methods in the following classes:

          UpdateOperation
          CopyRowsOperation
          DirectActions
          UpdateFieldOperation
          InsertOperation

          There may be reasons why some of these callers can be confident that they won't ever see a NoSpaceOnPage exception. However, I don't understand how we can prove that assertion for any of these classes. It's clear that NoSpaceOnPage can leak up to at least one of these classes (UpdateOperation), perhaps in several ways given the number of bugs we have seen with this stack trace.

          Is there some way that we can prove that NoSpaceOnPage won't escape to any of the other calling classes?

          Thanks,
          -Rick

          Show
          Rick Hillegas added a comment - Comments on DERBY-4577 and DERBY-4923 suggest that NoSpaceOnPage is a transient signal passed between methods inside StoredPage. If you grep the codeline, you see that StoredPage is the only class which mentions this exception. Low level logging methods throw NoSpaceOnPage to tell their callers that there isn't enough room on the page for the operation. The callers (in StoredPage) are supposed to allocate more space and then retry the operation. It seems that NoSpaceOnPage should never leak out of StoredPage. It should never escape to methods higher on the call stack. Does that sound correct? I am attaching derby-4923-tt-aa-NoSpaceOnPageExtendsException.diff. This patch changes NoSpaceOnPage, making it directly extend Exception so that it is no longer a StandardException. With this change you can see that it may be possible for NoSpaceOnPage to escape outside StoredPage to methods in the following classes: UpdateOperation CopyRowsOperation DirectActions UpdateFieldOperation InsertOperation There may be reasons why some of these callers can be confident that they won't ever see a NoSpaceOnPage exception. However, I don't understand how we can prove that assertion for any of these classes. It's clear that NoSpaceOnPage can leak up to at least one of these classes (UpdateOperation), perhaps in several ways given the number of bugs we have seen with this stack trace. Is there some way that we can prove that NoSpaceOnPage won't escape to any of the other calling classes? Thanks, -Rick
          Rick Hillegas made changes -
          Issue & fix info High Value Fix [ 10422 ] High Value Fix,Repro attached [ 10422, 10424 ]
          Rick Hillegas made changes -
          Attachment DERBY_4923.java [ 12537376 ]
          Hide
          Rick Hillegas added a comment -

          Attaching DERBY_4923.java. This reworks Mike's test case to be a standalone program rather than a JUnit test. If you run this with an insane engine, you get the stack trace indicated in this bug report. If you run this with a sane engine, you get an assertion.

          I don't know if it's significant that the test case compresses the table. However, table compression certainly takes us through code which has given rise to a lot of bugs.

          Show
          Rick Hillegas added a comment - Attaching DERBY_4923.java. This reworks Mike's test case to be a standalone program rather than a JUnit test. If you run this with an insane engine, you get the stack trace indicated in this bug report. If you run this with a sane engine, you get an assertion. I don't know if it's significant that the test case compresses the table. However, table compression certainly takes us through code which has given rise to a lot of bugs.
          Mike Matrigali made changes -
          Assignee Mike Matrigali [ mikem ]
          Hide
          Mike Matrigali added a comment -

          i had plans to look at this, but not top of my list. unassiging it for now and will change if I am actively working on it.

          Show
          Mike Matrigali added a comment - i had plans to look at this, but not top of my list. unassiging it for now and will change if I am actively working on it.
          Rick Hillegas made changes -
          Bug behavior facts Data corruption [ 10364 ]
          Hide
          Rick Hillegas added a comment -

          Hi Mike,

          This bug is assigned to you. Are you still working on it? Thanks.

          Show
          Rick Hillegas added a comment - Hi Mike, This bug is assigned to you. Are you still working on it? Thanks.
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-5858 [ DERBY-5858 ]
          Mike Matrigali made changes -
          Link This issue is related to DERBY-5450 [ DERBY-5450 ]
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-5581 [ DERBY-5581 ]
          Rick Hillegas made changes -
          Bug behavior facts [Wrong query result]
          Hide
          Rick Hillegas added a comment -

          Turning off the "Wrong query result" box. It seems to me that this bug does not return the wrong rows to the user. It raises an exception and fails.

          Show
          Rick Hillegas added a comment - Turning off the "Wrong query result" box. It seems to me that this bug does not return the wrong rows to the user. It raises an exception and fails.
          Mike Matrigali made changes -
          Labels derby_triage10_8
          Urgency Urgent
          Hide
          Mike Matrigali added a comment -

          reproducible serious bug setting urgency to urgent. Once hit the row can't be updated any more.

          triaged for 10.8.

          Show
          Mike Matrigali added a comment - reproducible serious bug setting urgency to urgent. Once hit the row can't be updated any more. triaged for 10.8.
          Kathey Marsden made changes -
          Component/s Store [ 11412 ]
          Mike Matrigali made changes -
          Field Original Value New Value
          Attachment derby4923repro.diff [ 12465015 ]
          Attachment derby.log [ 12465016 ]
          Hide
          Mike Matrigali added a comment -

          derby4923repro.diff is a repro of the bug in the form of a junit test to be run from the codeline. The attached derby.log shows the result from running it against a sane build.

          Show
          Mike Matrigali added a comment - derby4923repro.diff is a repro of the bug in the form of a junit test to be run from the codeline. The attached derby.log shows the result from running it against a sane build.
          Mike Matrigali created issue -

            People

            • Assignee:
              Mike Matrigali
              Reporter:
              Mike Matrigali
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development