Derby
  1. Derby
  2. DERBY-5098

embedded/in-memory: SQLNonTransientConnectionException: No current connection due to invalid page format

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0, 10.7.1.1, 10.8.1.2
    • Fix Version/s: 10.6.2.4, 10.7.1.4, 10.8.2.2, 10.9.1.0
    • Component/s: Store
    • Labels:
      None
    • Environment:
      OS: windows 2008 R2 x64, AIX 7.1, possibly other
      JVM: SUN/Oracle 1.6.0_24 server x64, IBM J9 Java5 vm2.3.sr12.j9vmap6423-20100630, possibly others
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Crash

      Description

      Hi

      In my case I am inserting many many rows in a in memory derby DB. After a while (a few minutes) I get a "SQLNonTransientConnectionException: No current connection" and the derby.log (see attachment) contains a complaint about an invalid page format with a dump of the page in question (which is completely zeros). The derby.log also contains another entry before the error (usually the same time stamp as the error): Cleanup action starting
      Maybe this is related to the error.
      Please find attached a test case to reproduce the issue. Just give it enough memory (-Xmx4g). It will insert a lot of rows to an in-memory derby DB with several threads over several connections. In case you want to run only one thread with one connection you might want to set these properties:
      -DuseSingleConnectionOnly=true -DuseSynchronousCommit=true -DnumberOfAsyncThreadsPerGenerator=1 -DnumberOfGeneratorThreads=1 -DnubmerOfRowsPerThread=100000000

      Thank you very much
      Christian

      1. DerbyRepro5098.java
        8 kB
        Christian Deutsch
      2. derby-5098-2a-remove_redundant_checks.diff
        1 kB
        Kristian Waagan
      3. derby-5098-1a-overflow_fixes.stat
        0.3 kB
        Kristian Waagan
      4. derby-5098-1a-overflow_fixes.diff
        2 kB
        Kristian Waagan
      5. derby.10.7.1.1.IBM_J9.java5.vm2.3.sr12.j9vmap6423-20100630.log
        81 kB
        Christian Deutsch
      6. derby.10.7.1.1_1.6.0_24.log
        120 kB
        Christian Deutsch
      7. derby.10.7.1.1_1.6.0_24__singleThreaded.log
        21 kB
        Christian Deutsch
      8. derby.10.6.1.0.IBM_J9.java5.vm2.3.sr12.j9vmap6423-20100630.log
        60 kB
        Christian Deutsch
      9. derby.10.6.1.0_1.6.0_24.log
        40 kB
        Christian Deutsch

        Activity

        Hide
        Kristian Waagan added a comment -

        Assigning issue to myself while doing some initial investigations.

        Show
        Kristian Waagan added a comment - Assigning issue to myself while doing some initial investigations.
        Hide
        Kristian Waagan added a comment -

        Attaching patch 1a, which fixes the problem reported.

        The bug is an int overflow, which causes the in-memory backend to allocate a new page instead of using the existing page. This is why the page contains zeros only.
        I also changed a few other places in the code where there's a possibility for int overflow, by casting one of the operands to long.

        A cautionary note about running the repro unmodified, it seems to require more than 20 GB to finish. Is this another observation of DERBY-2338?

        suites.All ran successfully on Solaris 11 Express with Java SE 6.

        Patch ready for review.

        Show
        Kristian Waagan added a comment - Attaching patch 1a, which fixes the problem reported. The bug is an int overflow, which causes the in-memory backend to allocate a new page instead of using the existing page. This is why the page contains zeros only. I also changed a few other places in the code where there's a possibility for int overflow, by casting one of the operands to long. A cautionary note about running the repro unmodified, it seems to require more than 20 GB to finish. Is this another observation of DERBY-2338 ? suites.All ran successfully on Solaris 11 Express with Java SE 6. Patch ready for review.
        Hide
        Knut Anders Hatlen added a comment -

        The changes in the patch look fine to me. +1 to commit.

        Since there is a check in increaseCapacity() that's making it a no-op in the case where the current capacity is larger than the requested capacity, maybe we could even remove the redundant checks around the calls to increaseCapacity()? Then we'd only have to worry about overflow at one place.

        Show
        Knut Anders Hatlen added a comment - The changes in the patch look fine to me. +1 to commit. Since there is a check in increaseCapacity() that's making it a no-op in the case where the current capacity is larger than the requested capacity, maybe we could even remove the redundant checks around the calls to increaseCapacity()? Then we'd only have to worry about overflow at one place.
        Hide
        Kristian Waagan added a comment -

        Thanks, Knut. I committed patch 1a to trunk with revision 1103681.

        I'll commit a patch with the suggested follow-up changes shortly.

        Show
        Kristian Waagan added a comment - Thanks, Knut. I committed patch 1a to trunk with revision 1103681. I'll commit a patch with the suggested follow-up changes shortly.
        Hide
        Kristian Waagan added a comment -

        Attached patch 2a, which removes the redundant checks as suggested by Knut.

        Committed to trunk with revision 1103718.

        I don't expect more work on this issue, but will keep the issue open for backporting. I'll look into that after checking the results of the nightly tests.

        Show
        Kristian Waagan added a comment - Attached patch 2a, which removes the redundant checks as suggested by Knut. Committed to trunk with revision 1103718. I don't expect more work on this issue, but will keep the issue open for backporting. I'll look into that after checking the results of the nightly tests.
        Hide
        Kristian Waagan added a comment -

        Back-ported fix:
        o 10.8: 1127842
        o 10.7: 1127843
        o 10.6: 1127844

        Resolving issue, ready for verification.

        Show
        Kristian Waagan added a comment - Back-ported fix: o 10.8: 1127842 o 10.7: 1127843 o 10.6: 1127844 Resolving issue, ready for verification.
        Hide
        Knut Anders Hatlen added a comment -

        [bulk update] Close all resolved issues that haven't been updated for more than one year.

        Show
        Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

          People

          • Assignee:
            Kristian Waagan
            Reporter:
            Christian Deutsch
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development