Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
3.0.10
-
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
- is caused by
-
MDEV-17252 mysql_stmt_fetch error during fetch of stored procedure (with cursor) results
-
- Stalled
-
-
MDEV-19321 Cursor flag set incorrectly in COM_STMT_EXECUTE response
-
- Open
-
- relates to
-
CONC-425 Segmentation fault in ma_alloc_root
-
- Closed
-
Activity
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: {noformat} sudo mysql -u root db1 < cursortest.sql {noformat} And then build the attached program: {noformat} g++ -ggdb -c $(mariadb_config --cflags) cursortest.cpp g++ -o cursortest cursortest.o $(mariadb_config --libs) {noformat} And then run the program. At that point, you should see an empty error: {noformat} $ ./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 {noformat} |
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: {noformat} sudo mysql -u root db1 < cursortest.sql {noformat} And then build the attached program: {noformat} g++ -ggdb -c $(mariadb_config --cflags) cursortest.cpp g++ -o cursortest cursortest.o $(mariadb_config --libs) {noformat} And then run the program. At that point, you should see an empty error: {noformat} $ ./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 {noformat} See |
Link | This issue is caused by MDEV-19321 [ MDEV-19321 ] |
Link | This issue is caused by MDEV-17252 [ MDEV-17252 ] |
Fix Version/s | 3.0.11 [ 23716 ] | |
Fix Version/s | 3.1.3 [ 23743 ] | |
Fix Version/s | 3.1 [ 23223 ] |
issue.field.resolutiondate | 2019-06-30 10:51:50.0 | 2019-06-30 10:51:50.479 |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Closed [ 6 ] |
Link | This issue relates to MDEV-19321 [ MDEV-19321 ] |
Link | This issue relates to MDEV-19321 [ MDEV-19321 ] |
Workflow | MariaDB connectors [ 97863 ] | MariaDB v4 [ 161177 ] |
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
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).