Derby
  1. Derby
  2. DERBY-5421

NullPointerException during system.nstest.utils.Dbutil.update_one_row

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Windows XP (embedded), SUSE Linux (10) (client/server), both with ibm 1.6 SR9 FP1
    • Bug behavior facts:
      Regression, Regression Test Failure

      Description

      The nstest - both embedded (on Windows XP) and client/server configuration (on SUSE Linux 10) ran into a NullPointerException during the call to update_one_row.
      The test only ran for 5 days, vs. 10.8.1.2 8 days, and I've never seen this error before:

      sample (console) output:
      total memory: 20962816 free: 3036264 Wed Sep 14 00:28:00 PDT 2011
      TObj -->NULL error message detected
      TObj -->Here is the NULL exception - java.lang.NullPointerException
      TObj -->Stack trace of the NULL exception - java.lang.NullPointerException
      at org.apache.derbyTesting.system.nstest.utils.DbUtil.update_one_row(DbUtil.java:275)
      at org.apache.derbyTesting.system.nstest.tester.TesterObject.doIUDOperation(TesterObject.java:162)
      at org.apache.derbyTesting.system.nstest.tester.Tester2.startTesting(Tester2.java:109)
      at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:555)
      TObj -->At this point - executing update_one_row, exception thrown was : null
      TObj -->NULL error message detected
      TObj -->Here is the NULL exception - java.lang.NullPointerException
      TObj -->Stack trace of the NULL exception - java.lang.NullPointerException
      at org.apache.derbyTesting.system.nstest.utils.DbUtil.update_one_row(DbUtil.java:275)
      at org.apache.derbyTesting.system.nstest.tester.TesterObject.doIUDOperation(TesterObject.java:162)
      at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tester1.java:118)
      at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551)
      TObj -->At this point - executing update_one_row, exception thrown was : null

      Looking at the source of nstest.utils.DbUtil.update_one_row it's calling ps2.close():

      ----------------------------
      ....
      column = colnames[ind % NUMTYPES]; // randomly gets one of the columns
      // of the table

      try

      { ps2 = conn.prepareStatement(" update nstesttab set " + column + " = ? " + " where serialkey = " + skey); }

      catch (Exception e)

      { ps2.close(); printException( "closing update prepared stmt in dbUtil.update_one_row() ", e); return rowsUpdated; }

      ....
      ----------------------------

      At first glance, this seems a test issue, but I think it possible the test is hiding something more interesting, so I'm not marking this as component 'test'.

      1. DERBY-5421_1.diff
        1 kB
        Myrna van Lunteren
      2. DERBY-5421_2.diff
        8 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Mamta A. Satoor added a comment -

          I did a quick glance at the code around the null pointer exception area nstest.utils.DbUtil.update_one_row(DbUtil.java:275) and found that in case of exception, we do following
          } catch (Exception e) {
          ps2.close();
          printException(
          "closing update prepared stmt in dbUtil.update_one_row() ",
          e);

          One definite improvement to the test would be to first print the exception and then do the ps2.close so we know what was the exact exception. But this is for future runs. Myrna I think already mentioned that when the test gets run next time, she will run it with more diagnostic properties like derby.language.logStatementText=true and derby.stream.error.logSeverityLevel=0

          Show
          Mamta A. Satoor added a comment - I did a quick glance at the code around the null pointer exception area nstest.utils.DbUtil.update_one_row(DbUtil.java:275) and found that in case of exception, we do following } catch (Exception e) { ps2.close(); printException( "closing update prepared stmt in dbUtil.update_one_row() ", e); One definite improvement to the test would be to first print the exception and then do the ps2.close so we know what was the exact exception. But this is for future runs. Myrna I think already mentioned that when the test gets run next time, she will run it with more diagnostic properties like derby.language.logStatementText=true and derby.stream.error.logSeverityLevel=0
          Hide
          Rick Hillegas added a comment -

          I agree with Kathey that this error may be fallout from an ungraceful recovery after the error seen in DERBY-5423. Setting derby.language.sequence.preallocator=200 may help this test run longer before it stumbles over too much contention on the identity column. That is not to say that we shouldn't add defensive logic to the test so that it recovers more gracefully.

          Show
          Rick Hillegas added a comment - I agree with Kathey that this error may be fallout from an ungraceful recovery after the error seen in DERBY-5423 . Setting derby.language.sequence.preallocator=200 may help this test run longer before it stumbles over too much contention on the identity column. That is not to say that we shouldn't add defensive logic to the test so that it recovers more gracefully.
          Hide
          Mamta A. Satoor added a comment -

          While we are at it, I think the defensive logic in DbUtil.update_one_row can look as follows
          try

          { ps2 = conn.prepareStatement(" update nstesttab set " + column + " = ? " + " where serialkey = " + skey); }

          catch (Exception e)

          { printException( "closing update prepared stmt in dbUtil.update_one_row() ", e); if (ps2 != null) ps2.close(); return rowsUpdated; }

          With this change, even if ps2 is null for some reason, we would not run into NPE and the exception would be recorded for debugging. The similar error handling exists in DbUtil.pick_one.

          Show
          Mamta A. Satoor added a comment - While we are at it, I think the defensive logic in DbUtil.update_one_row can look as follows try { ps2 = conn.prepareStatement(" update nstesttab set " + column + " = ? " + " where serialkey = " + skey); } catch (Exception e) { printException( "closing update prepared stmt in dbUtil.update_one_row() ", e); if (ps2 != null) ps2.close(); return rowsUpdated; } With this change, even if ps2 is null for some reason, we would not run into NPE and the exception would be recorded for debugging. The similar error handling exists in DbUtil.pick_one.
          Hide
          Knut Anders Hatlen added a comment -

          If the statement inside the try block raises an exception, ps2 is definitely going to be null in the catch block, so I'd rather remove the closing altogether. Apart from that, the suggested changes sound good to me.

          Show
          Knut Anders Hatlen added a comment - If the statement inside the try block raises an exception, ps2 is definitely going to be null in the catch block, so I'd rather remove the closing altogether. Apart from that, the suggested changes sound good to me.
          Hide
          Myrna van Lunteren added a comment -

          I was didn't notice this last comment, and have run a couple of days with every ps.close() in DbUtils.java framed by a if (ps != n ull)
          ps.close()
          (or ps2, if that's what it was).

          This run showed a ton of 40001 errors DERBY-5428 - not sure if that's what was going on before, but also further NullPointerExceptions like this:

          TObj -->Here is the NULL exception - java.lang.NullPointerException
          TObj -->Stack trace of the NULL exception -
          java.lang.NullPointerException
          at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe
          ration(TesterObject.java:239)
          at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes
          ter1.java:102)
          at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551)
          TObj -->At this point - processing ResultSet during row data retrieval, exceptio
          n thrown was : null
          --> Isolation Level is TRANSACTION_READ_UNCOMMITTED, hence SHOULD NOT FAIL *****

                • doSelect in thread Tester1Thread 2 threw java.lang.NullPointerException
                  TObj -->NULL error message detected
                  TObj -->Here is the NULL exception - java.lang.NullPointerException
                  TObj -->Stack trace of the NULL exception -
                  java.lang.NullPointerException
                  at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe
                  ration(TesterObject.java:298)
                  at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes
                  ter1.java:102)
                  at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551)
                  TObj -->At this point - doSelectOperation(), exception thrown was : null
                  java.lang.NullPointerException
                  at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe
                  ration(TesterObject.java:298)
                  at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes
                  ter1.java:102)
                  at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551)
          Show
          Myrna van Lunteren added a comment - I was didn't notice this last comment, and have run a couple of days with every ps.close() in DbUtils.java framed by a if (ps != n ull) ps.close() (or ps2, if that's what it was). This run showed a ton of 40001 errors DERBY-5428 - not sure if that's what was going on before, but also further NullPointerExceptions like this: TObj -->Here is the NULL exception - java.lang.NullPointerException TObj -->Stack trace of the NULL exception - java.lang.NullPointerException at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe ration(TesterObject.java:239) at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes ter1.java:102) at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551) TObj -->At this point - processing ResultSet during row data retrieval, exceptio n thrown was : null --> Isolation Level is TRANSACTION_READ_UNCOMMITTED, hence SHOULD NOT FAIL ***** doSelect in thread Tester1Thread 2 threw java.lang.NullPointerException TObj -->NULL error message detected TObj -->Here is the NULL exception - java.lang.NullPointerException TObj -->Stack trace of the NULL exception - java.lang.NullPointerException at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe ration(TesterObject.java:298) at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes ter1.java:102) at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551) TObj -->At this point - doSelectOperation(), exception thrown was : null java.lang.NullPointerException at org.apache.derbyTesting.system.nstest.tester.TesterObject.doSelectOpe ration(TesterObject.java:298) at org.apache.derbyTesting.system.nstest.tester.Tester1.startTesting(Tes ter1.java:102) at org.apache.derbyTesting.system.nstest.NsTest.run(NsTest.java:551)
          Hide
          Myrna van Lunteren added a comment -

          Attaching the (10.8 branch) diff of the change adding if (ps != nul) to every ps*.close() call.

          Not for commit.

          Show
          Myrna van Lunteren added a comment - Attaching the (10.8 branch) diff of the change adding if (ps != nul) to every ps*.close() call. Not for commit.
          Hide
          Myrna van Lunteren added a comment -

          Posting another patch, against 10.8 branch, which does away with all the ps*.closes, and also adds an if (rSet != null) to TesterObject.

          Show
          Myrna van Lunteren added a comment - Posting another patch, against 10.8 branch, which does away with all the ps*.closes, and also adds an if (rSet != null) to TesterObject.
          Hide
          Myrna van Lunteren added a comment -

          committed patch DERBY-5421_2.diff to 10.8 with revision 1177474 and merged it back up to trunk with revision 1177475.

          Show
          Myrna van Lunteren added a comment - committed patch DERBY-5421 _2.diff to 10.8 with revision 1177474 and merged it back up to trunk with revision 1177475.
          Hide
          Myrna van Lunteren added a comment -

          I think the changes for this particular issue are complete.

          Show
          Myrna van Lunteren added a comment - I think the changes for this particular issue are complete.
          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:
              Unassigned
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development