Derby
  1. Derby
  2. DERBY-1208

Attempts to reuse a prepared statement after an execution-time error causes ASSERT failure in SANE mode, but work fine in INSANE.

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: None
    • Component/s: JDBC
    • Urgency:
      Low
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Seen in production

      Description

      Please see the comments in DERBY-1196 for the discussion that prompted the filing of this issue. In short, if one attempts to reuse a prepared statement with a new set of parameters after a previous call to execute that statement has failed, the result will be an ASSERT failure in SANE mode. When the same thing is done in INSANE mode, everything works as one might expect it to.

      1. 1208.diff
        6 kB
        Håvard Mork
      2. d1208.java
        3 kB
        A B
      3. derby.log
        5 kB
        A B

        Activity

        Hide
        Kathey Marsden added a comment -

        Thanks Dan for looking at the patch. I'll hold off on further action and will uncheck "patch available" based on Dan's concern with the code change and the test issue.

        Håvard are you still interested in working on this issue? If so please make sure you speak up if you need help and assign yourself and mark patch available when you have a new patch you would like someone to review. I would like to help move it along if I can as I think it is very wrong that we made you wait three months for review. Please look at the Wiki page http://wiki.apache.org/db-derby/PatchAdvice for some tips on how to push your patch through the process too.

        Show
        Kathey Marsden added a comment - Thanks Dan for looking at the patch. I'll hold off on further action and will uncheck "patch available" based on Dan's concern with the code change and the test issue. Håvard are you still interested in working on this issue? If so please make sure you speak up if you need help and assign yourself and mark patch available when you have a new patch you would like someone to review. I would like to help move it along if I can as I think it is very wrong that we made you wait three months for review. Please look at the Wiki page http://wiki.apache.org/db-derby/PatchAdvice for some tips on how to push your patch through the process too.
        Hide
        Daniel John Debrunner added a comment -

        The modified test prepStmtNull succeeds (in sane & insane) for me without applying the code changes to the ResultSets.
        The repro d1208.java does fail for me in sane mode. (and passes in insane).

        Show
        Daniel John Debrunner added a comment - The modified test prepStmtNull succeeds (in sane & insane) for me without applying the code changes to the ResultSets. The repro d1208.java does fail for me in sane mode. (and passes in insane).
        Hide
        Daniel John Debrunner added a comment -

        I'm not sure this is the correct approach, but I need to investigate more. Typically (I think) we don't have finally blocks in the language ResultSet classes that close other ResultSets. I think this is handled at a higher level by closing the entire ResultSet tree. The patch is useful in that it points out the issue and provides a test. It potentially indicates that there is an issue with close methods for the two modified ResultSet implementations, e.g. the closeSource method in GroupedAggregateResultSet has one path where the source ResultSet is not closed, that logic looks strange.

        Show
        Daniel John Debrunner added a comment - I'm not sure this is the correct approach, but I need to investigate more. Typically (I think) we don't have finally blocks in the language ResultSet classes that close other ResultSets. I think this is handled at a higher level by closing the entire ResultSet tree. The patch is useful in that it points out the issue and provides a test. It potentially indicates that there is an issue with close methods for the two modified ResultSet implementations, e.g. the closeSource method in GroupedAggregateResultSet has one path where the source ResultSet is not closed, that logic looks strange.
        Hide
        Kathey Marsden added a comment -

        Thanks Håvard for the patch and the test. It is especially good that we will now have coverage for failures during this part of execution.

        Your approach looks good to me. I ran the test and verified the original repro fails without your patch and passes with it.

        I wouldn't normally commit in this area but the patch looks pretty harmless, so if nobody objects, I will run derbyall and then commit Monday. It would be good if someone familiar with the SQL area also took a quick look.

        Kathey

        Show
        Kathey Marsden added a comment - Thanks Håvard for the patch and the test. It is especially good that we will now have coverage for failures during this part of execution. Your approach looks good to me. I ran the test and verified the original repro fails without your patch and passes with it. I wouldn't normally commit in this area but the patch looks pretty harmless, so if nobody objects, I will run derbyall and then commit Monday. It would be good if someone familiar with the SQL area also took a quick look. Kathey
        Hide
        Håvard Mork added a comment -

        The attached patch fixes this harmless warning in embedded mode. Also fixed the same problem for 'group by' result sets.

        Show
        Håvard Mork added a comment - The attached patch fixes this harmless warning in embedded mode. Also fixed the same problem for 'group by' result sets.
        Hide
        A B added a comment -

        Attaching a simple repro for this issue. To run against embedded mode, run:

        > java d1208 embedded

        I've also attached the derby.log file created from running the repro.

        Against a SANE set of jars the output is:


        Using driver: org.apache.derby.jdbc.EmbeddedDriver

        Query 1 result set: 10, Row 1
        Query 2 result set: 20, Row 2
        Query 3 failed as expected: Attempt to divide by zero.
        Query 4 failed: Java exception: 'ASSERT FAILED ProjectRestrictResultSet already open: org.apache.der
        by.shared.common.sanity.AssertFailure'.
        Query 5 failed: Java exception: 'ASSERT FAILED ProjectRestrictResultSet already open: org.apache.der
        by.shared.common.sanity.AssertFailure'.

        Database shutdown.

        [ Done. ]


        With INSANE jars, the output is:


        Using driver: org.apache.derby.jdbc.EmbeddedDriver

        Query 1 result set: 10, Row 1
        Query 2 result set: 20, Row 2
        Query 3 failed as expected: Attempt to divide by zero.
        Query 4 result set: 40, Row 4
        Query 5 result set: 50, Row 5

        Database shutdown.

        [ Done. ]

        Show
        A B added a comment - Attaching a simple repro for this issue. To run against embedded mode, run: > java d1208 embedded I've also attached the derby.log file created from running the repro. Against a SANE set of jars the output is: Using driver: org.apache.derby.jdbc.EmbeddedDriver Query 1 result set: 10, Row 1 Query 2 result set: 20, Row 2 Query 3 failed as expected: Attempt to divide by zero. Query 4 failed: Java exception: 'ASSERT FAILED ProjectRestrictResultSet already open: org.apache.der by.shared.common.sanity.AssertFailure'. Query 5 failed: Java exception: 'ASSERT FAILED ProjectRestrictResultSet already open: org.apache.der by.shared.common.sanity.AssertFailure'. Database shutdown. [ Done. ] With INSANE jars, the output is: Using driver: org.apache.derby.jdbc.EmbeddedDriver Query 1 result set: 10, Row 1 Query 2 result set: 20, Row 2 Query 3 failed as expected: Attempt to divide by zero. Query 4 result set: 40, Row 4 Query 5 result set: 50, Row 5 Database shutdown. [ Done. ]

          People

          • Assignee:
            Unassigned
            Reporter:
            A B
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development