| Bug #47485 | mysql_store result returns a result set for a prepared statement | ||
|---|---|---|---|
| Submitted: | 21 Sep 2009 15:14 | Modified: | 8 Oct 2010 14:35 |
| Reporter: | Ulf Wendel | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: C API (client library) | Severity: | S3 (Non-critical) |
| Version: | 5.1 | OS: | Any |
| Assigned to: | Dmitry Shulga | CPU Architecture: | Any |
[21 Sep 2009 15:14]
Ulf Wendel
[21 Sep 2009 15:14]
Ulf Wendel
Test program
Attachment: statement_store.c (text/x-csrc), 2.20 KiB.
[21 Sep 2009 19:52]
Sveta Smirnova
Thank you for the report. Verified as described.
[21 Jul 2010 8:32]
Konstantin Osipov
An attempt to do mysql_store_result() or mysql_use_result() after mysql_stmt_execute() should lead to "Сommands out of sync" error. Dmitry, please implement this and pass it on to Paul to document in the manual.
[27 Jul 2010 8:53]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/114411 3456 Dmitry Shulga 2010-07-27 Fixed bug #47485 - mysql_store_result returns a not NULL result set for a prepared statement. @ include/mysql.h enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ include/mysql.h.pp enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ libmysql/libmysql.c Introduce a separate mysql state to distinguish the situation when we have a binary result set pending on the server from the situation when the result set is in text protocol. execute() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT before return. stmt_read_row_unbuffered() and mysql_stmt_store_result() were modified: added checking for mysql->status against MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT.
[29 Jul 2010 11:00]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/114624 3456 Dmitry Shulga 2010-07-29 Fixed bug #47485 - mysql_store_result returns a not NULL result set for a prepared statement. @ include/mysql.h enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ include/mysql.h.pp enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ libmysql/libmysql.c Introduce a separate mysql state to distinguish the situation when we have a binary result set pending on the server from the situation when the result set is in text protocol. execute() modified: if mysql->status == MYSQL_STATUS_GET_RESULT before return then set it to value MYSQL_STATUS_STATEMENT_GET_RESULT. stmt_read_row_unbuffered() and mysql_stmt_store_result() were modified: added checking for mysql->status against MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT. @ tests/mysql_client_test.c added test_bug47485()
[7 Sep 2010 7:20]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/117667 3499 Dmitry Shulga 2010-09-07 Fixed bug #47485 - mysql_store_result returns a not NULL result set for a prepared statement. @ include/mysql.h enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ include/mysql.h.pp enumerator MYSQL_STATUS_STATEMENT_GET_RESULT was added into mysql_status enum. @ libmysql/libmysql.c Introduce a separate mysql state to distinguish the situation when we have a binary result set pending on the server from the situation when the result set is in text protocol. execute() modified: if mysql->status == MYSQL_STATUS_GET_RESULT before return then set it to value MYSQL_STATUS_STATEMENT_GET_RESULT. stmt_read_row_unbuffered() and mysql_stmt_store_result() were modified: added checking for mysql->status against MYSQL_STATUS_STATEMENT_GET_RESULT value instead of MYSQL_STATUS_GET_RESULT. @ tests/mysql_client_test.c added test_bug47485()
[8 Sep 2010 10:27]
Bjørn Munch
It looks like this fix is causing mysql_client_test to fail in the subtest test_wl4435 (not the one that was added). From my run:
---
#####################################
225 of (1/1): test_wl4435
#####################################
exec_counter: 0
num_fields: 4
- 0: name: 'a1'/'a1'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
- 1: name: 'a2'/'a2'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 32; max_length: 0; type: 254; decimals: 0
- 2: name: 'a3'/'a3'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 4; max_length: 0; type: 5; decimals: 2
- 3: name: 'a4'/'a4'; table: 't1'/'t1'; db: 'client_test_db'; catalog: 'def'; length: 5; max_length: 0; type: 246; decimals: 1
Data:
int: 1; str: '11'; dbl: 12.340000; dec: '56.7';
int: 2; str: '12'; dbl: 56.780000; dec: '90.1';
int: 3; str: '13'; dbl: 23.450000; dec: '67.8';
EOF
mysql_stmt_next_result(): 0; field_count: 5
num_fields: 5
- 0: name: 'b0'/'b0'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
- 1: name: 'b1'/'b1'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 11; max_length: 0; type: 3; decimals: 0
- 2: name: 'b2'/'b2'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 32; max_length: 0; type: 254; decimals: 0
- 3: name: 'b3'/'b3'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 4; max_length: 0; type: 5; decimals: 2
- 4: name: 'b4'/'b4'; table: 't2'/'t2'; db: 'client_test_db'; catalog: 'def'; length: 5; max_length: 0; type: 246; decimals: 1
Data:
EOF
mysql_stmt_next_result(): 2014; field_count: 5
Error: Commands out of sync; you can't run this command now (errno: 2014)
/home/bm136801/my/merge-nx/tests/mysql_client_test.c:1934: check failed: 'rc > 0'
----
Line 1934 is here in my sandbox:
if (rc > 0)
{
printf("Error: %s (errno: %d)\n",
mysql_stmt_error(stmt), mysql_stmt_errno(stmt));
>>> DIE(rc > 0);
}
See also PB2 for mysql-5.5-merge.
[9 Sep 2010 12:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/117858 3196 Dmitry Shulga 2010-09-09 Fix mysql_client_test failure introduced by a patch for Bug#47485. The problem was that mysql_stmt_next_result() (new to 5.5) was not properly updated. @ libmysql/libmysql.c mysql_stmt_next_result() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT before return if there is a result set.
[9 Sep 2010 12:38]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/117860 3197 Dmitry Shulga 2010-09-09 Fix mysql_client_test failure introduced by a patch for Bug#47485. The problem was that mysql_stmt_next_result() (new to 5.5) was not properly updated. @ libmysql/libmysql.c mysql_stmt_next_result() modified: set mysql->status= MYSQL_STATUS_STATEMENT_GET_RESULT before return if there is a result set.
[9 Sep 2010 13:21]
Ulf Wendel
How are libmysql and C/C sources keept in sync: will this be fixed in C/C as well, assuming it also affects C/C?
[10 Sep 2010 9:05]
Dmitry Shulga
Pushed to mysql-5.1-bugteam. Merged and pushed to mysql-5.5-merge.
[28 Sep 2010 15:38]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@sun.com-20100928153607-tdsxkdm5cmuym5sq) (version source revid:alik@sun.com-20100928153508-0saa6v93dinqx1u7) (merge vers: 5.6.1-m4) (pib:21)
[28 Sep 2010 15:41]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100928153646-pqp8o1a92mxtuj3h) (version source revid:alik@sun.com-20100928153532-lr3gtvnyp2en4y75) (pib:21)
[28 Sep 2010 15:43]
Bugs System
Pushed into mysql-5.5 5.5.7-rc (revid:alik@sun.com-20100928153459-4nudf4zgzlou4s7q) (version source revid:alik@sun.com-20100928153459-4nudf4zgzlou4s7q) (merge vers: 5.5.7-rc) (pib:21)
[4 Oct 2010 15:10]
Paul DuBois
Noted in 5.5.7, 5.6.1 changelogs. mysql_store_result() and mysql_use_result() are not for use with prepared statements and are not intended to be called following mysql_stmt_execute(), but failed to return an error when invoked that way. Also updated mysql_stmt_execute() section. Setting report to Need Merge pending push to 5.1.x.
[8 Oct 2010 14:35]
Paul DuBois
Noted in 5.1.52 changelog.
[1 Nov 2010 19:00]
Bugs System
Pushed into mysql-5.1 5.1.53 (revid:build@mysql.com-20101101184443-o2olipi8vkaxzsqk) (version source revid:build@mysql.com-20101101184443-o2olipi8vkaxzsqk) (merge vers: 5.1.53) (pib:21)
