Derby
  1. Derby
  2. DERBY-2864

LOB import unexpectedly succeeds on corrupt data

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: None
    • Component/s: SQL
    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      I exported a lob-bearing table using the SYSCS_UTIL.SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE procedure. Then I edited the export file to change the length of one of the lobs to an absurdly large number (500K). Then I ran SYSCS_UTIL.SYSCS_IMPORT_DATA_LOBS_FROM_EXTFILE. I expected this command would fail while trying to read beyond the end of the lob file. However, it succeeded.

      I think that the import should fail, and the user should see an exception which identifies the line number and column number holding the corrupt lob pointer. I will attach a test case.

      1. importLobBug.tar
        16 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Attaching a tar file which contains the test case. The tar file contains the following files:

          script.sql

          Run this through ij to reproduce the bug.

          test-export-table3.dat

          This is the file with the corrupt lob pointer.

          test-export-table1-lobs.dat

          This is the file containing the lobs.

          Show
          Rick Hillegas added a comment - Attaching a tar file which contains the test case. The tar file contains the following files: script.sql Run this through ij to reproduce the bug. test-export-table3.dat This is the file with the corrupt lob pointer. test-export-table1-lobs.dat This is the file containing the lobs.
          Hide
          Myrna van Lunteren added a comment -

          Does this need to be fixed in 10.3.1.1?
          If not, I'll unset the fix-in...

          Show
          Myrna van Lunteren added a comment - Does this need to be fixed in 10.3.1.1? If not, I'll unset the fix-in...
          Hide
          Rick Hillegas added a comment -

          Unsetting the fix-in flag. It would be nice to fix this bug before the feature is exposed but time is running out for 10.3.

          Show
          Rick Hillegas added a comment - Unsetting the fix-in flag. It would be nice to fix this bug before the feature is exposed but time is running out for 10.3.
          Hide
          Rick Hillegas added a comment -

          Triage for 10.5.2: Assign normal urgency.

          Show
          Rick Hillegas added a comment - Triage for 10.5.2: Assign normal urgency.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development