Uploaded image for project: 'MariaDB Connector/C'
  1. MariaDB Connector/C
  2. CONC-424

mysql_stmt_store_result returns empty error

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 3.0.10
    • 3.0.11, 3.1.3
    • None
    • None

    Description

      The mysql_stmt_store_result function can return an error, even though mysql_stmt_errno(), mysql_stmt_sqlstate(), and mysql_stmt_error() do not actually contain information about an error. This may be related to running stored procedures that contain a cursor.

      To reproduce, load the attached schema:

      sudo mysql -u root db1 < cursortest.sql
      

      And then build the attached program:

      g++ -ggdb -c $(mariadb_config --cflags) cursortest.cpp
      g++ -o cursortest cursortest.o $(mariadb_config --libs)
      

      And then run the program.

      At that point, you should see an empty error:

      $ ./cursortest
      Query: CALL testCursor()
      Failed to store result. Error 0 (00000):
      Result set #1 had 0 rows
      Received 1 result sets
      Query: CALL testNoCursor()
      Segmentation fault
      

      See CONC-425 about the segmentation fault.

      Attachments

        Issue Links

          Activity

            georg Georg Richter added a comment -

            Server sends the flag SERVER_STATUS_CURSOR_EXISTS to force the client to retrive rows by sending COM_STMT_FETCH. This doesn't work, since

            • client didn't specify a cursor
            • com_stmt_fetch can't be used while processing result sets and will end up in a "commands out of sync" error

            This is a server bug in all versions (including MySQL server).
            A workaround would be to check additionally for stmt->flags & CURSOR_TYPE_READ_ONLY to make sure, that the client opened a cursor.

            Since text and binary protocol use the same function, the stmt->error is not updated correctly (which is a bug).

            georg Georg Richter added a comment - Server sends the flag SERVER_STATUS_CURSOR_EXISTS to force the client to retrive rows by sending COM_STMT_FETCH. This doesn't work, since client didn't specify a cursor com_stmt_fetch can't be used while processing result sets and will end up in a "commands out of sync" error This is a server bug in all versions (including MySQL server). A workaround would be to check additionally for stmt->flags & CURSOR_TYPE_READ_ONLY to make sure, that the client opened a cursor. Since text and binary protocol use the same function, the stmt->error is not updated correctly (which is a bug).
            georg Georg Richter added a comment -

            commit d09ac51df3c35e569e91313affb58ae74fd3470a
            Author: Georg Richter <georg@mariadb.com>
            Date: Sun Jun 30 12:41:42 2019 +0200

            Workaround/Fix for CONC-424:

            1) In case a cursor is used in a stored procedure server sends a SERVER_STATUS_CURSOR_EXISTS flag,
            even if the client didn't open a cursor via mysql_stmt_attr_set. This ends in a "comands out of sync" error,
            since the client is sending a COM_STMT_FETCH command while the result sets were not read before.
            We check now in case server sends a SERVER_STATUS_CURSOR_EXIST flag, if the client opened a cursor before.

            2) The stmt error codes weren't update for all COM_STMT* commands correctly, e.g. COM_STMT_FETCH didn't show an error even if it failed.

            georg Georg Richter added a comment - commit d09ac51df3c35e569e91313affb58ae74fd3470a Author: Georg Richter <georg@mariadb.com> Date: Sun Jun 30 12:41:42 2019 +0200 Workaround/Fix for CONC-424 : 1) In case a cursor is used in a stored procedure server sends a SERVER_STATUS_CURSOR_EXISTS flag, even if the client didn't open a cursor via mysql_stmt_attr_set. This ends in a "comands out of sync" error, since the client is sending a COM_STMT_FETCH command while the result sets were not read before. We check now in case server sends a SERVER_STATUS_CURSOR_EXIST flag, if the client opened a cursor before. 2) The stmt error codes weren't update for all COM_STMT* commands correctly, e.g. COM_STMT_FETCH didn't show an error even if it failed.

            People

              georg Georg Richter
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.