Bug #89214 | The SELECT will deadlock in the stored procedure, if the result set is empty. | ||
---|---|---|---|
Submitted: | 12 Jan 2018 19:30 | Modified: | 3 Oct 2018 1:40 |
Reporter: | two pg | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Prepared statements | Severity: | S2 (Serious) |
Version: | 5.7,5.7.17,5.7.20,5.7.21 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[12 Jan 2018 19:30]
two pg
[12 Jan 2018 19:37]
two pg
source code
Attachment: mysql-bug-data-89214.zip (application/x-zip-compressed, text), 1.89 KiB.
[17 Jan 2018 14:26]
MySQL Verification Team
Hi! Thank you for your report. We need to know whether you observe this phenomena if you do not use prepared statements ??? Also, we need to know whether your program gets stuck in this line: if (mysql_stmt_execute(stmt)) Next, stored procedures return two or more result sets. And I do not see where do you clear both result sets in your code. Last, but not least, what is shown in the processlist when your program gets stuck ????
[19 Jan 2018 14:35]
two pg
Yes, we are stuck in this line if result set is empty. if (mysql_stmt_execute(stmt)) This Bug only happen in the use of mysql_stmt_*, does not occur in the use of mysql_real_*. Must use mysql client 5.7.x and mysql server 5.7.x to repeat. Other versions do not have this problem. This is just a test code, eliminating a lot of detail. We found this problem in our asynchronous mysql connection library as we upgraded mysql 5.5 / 5.6 to mysql 5.7. mysql> show processlist; +----+------+--------------------+-------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+------+--------------------+-------+---------+------+----------+------------------+ | 6 | root | DESKTOP-7700:50460 | NULL | Sleep | 164 | | NULL | | 7 | root | localhost:50468 | appdb | Sleep | 304 | | NULL | | 12 | root | localhost:50511 | NULL | Query | 0 | starting | show processlist | +----+------+--------------------+-------+---------+------+----------+------------------+ 3 rows in set (0.00 sec)
[23 Jan 2018 13:19]
MySQL Verification Team
Hi! Please, clear out one more detail. You wrote that you use "our asynchronous MySQL connection library". Does it mean that you do not use our library ??? If that is the case, we can not debug your problem, since it could be related to your library behaviour. Thanks in advance !!!!
[23 Jan 2018 13:39]
MySQL Verification Team
Hi! To make things simpler, can you repeat this problem with our own libmysqlclient library ???
[23 Jan 2018 14:05]
MySQL Verification Team
Use the latest libmysqlclient library that comes with our 5.7 package.
[24 Jan 2018 0:01]
two pg
No, we use libmysqlclient, version 5.7.21
[24 Jan 2018 0:01]
two pg
new source code
Attachment: mysql-bug-data2-89214.zip (application/x-zip-compressed, text), 4.82 KiB.
[24 Jan 2018 0:04]
two pg
source code is copy from https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-execute.html
[24 Jan 2018 0:06]
two pg
5.6.39 passed the test. log-5.6.39: E:\TestMysql\x64\Release\TestMysql.exe MYSQL server version: 5.6.39-log MYSQL client version: 5.6.39 ----------------Test5---------------- ------------------------------------- sql = call SP_GET_TEST_TABLE(1) ---------------begin----------------- prepare, SELECT successful total parameters in SELECT: 0 total columns in SELECT statement: 4 Fetching results ... Query Finished ... ----------------end------------------
[24 Jan 2018 0:14]
two pg
5.7.21 Test failed, stuck in mysql_stmt_execute(). E:\TestMysql\x64\Release\TestMysql.exe MYSQL server version: 5.7.21-log MYSQL client version: 5.7.21 ----------------Test5---------------- ------------------------------------- sql = call SP_GET_TEST_TABLE(1) ---------------begin----------------- prepare, SELECT successful total parameters in SELECT: 0 ^C E:\TestMysql\x64\Release>
[24 Jan 2018 0:22]
two pg
Passed the test. E:\TestMysql\x64\Release\TestMysql.exe MYSQL server version: 5.7.21-log MYSQL client version: 5.6.39 ----------------Test5---------------- ------------------------------------- sql = call SP_GET_TEST_TABLE(1) ---------------begin----------------- prepare, SELECT successful total parameters in SELECT: 0 total columns in SELECT statement: 4 Fetching results ... Query Finished ... ----------------end------------------
[24 Jan 2018 0:23]
two pg
Passed the test. E:\TestMysql\x64\Release\TestMysql.exe MYSQL server version: 5.6.39-log MYSQL client version: 5.7.21 ----------------Test5---------------- ------------------------------------- sql = call SP_GET_TEST_TABLE(1) ---------------begin----------------- prepare, SELECT successful total parameters in SELECT: 0 total columns in SELECT statement: 4 Fetching results ... Query Finished ... ----------------end------------------
[24 Jan 2018 1:00]
two pg
This problem is very easy to repeat, You must use mysql server 5.7.x and libmysqlclient 5.7.x. We tested 5.7.11, 5.7.13, 5.7.17, 5.7.20, 5.7.21, all can find this problem. The main flow of our asynchronous library is similar to this code. https://dev.mysql.com/doc/refman/5.7/en/mysql-stmt-execute.html see: https://bugs.mysql.com/file.php?id=26408&bug_id=89214
[24 Jan 2018 16:02]
MySQL Verification Team
Hi! Actually, I get a bit different results. Yes, the program prints out to stdout the same status messages: stmt_prepare begin stmt_prepare successful stmt_execute begin But, processlist is different: +----+--------+-----------------+-------+---------+------+----------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+--------+-----------------+-------+---------+------+----------+------------------+ | 5 | sinisa | localhost:51017 | appdb | Sleep | 204 | | NULL | | 8 | sinisa | localhost | NULL | Query | 0 | starting | show processlist | +----+--------+-----------------+-------+---------+------+----------+------------------+ is that the same that you see ???? A long sleep ......
[25 Jan 2018 3:28]
two pg
No different, it's the same. please check the previous comment.
[25 Jan 2018 13:23]
MySQL Verification Team
Hi! I tried recoding your test case in several ways, but it never worked. Verified as reported.
[3 Oct 2018 1:40]
Paul DuBois
Posted by developer: Fixed in 5.7.25, 8.0.14. When executing a prepared statement with a procedure call with the CURSOR_TYPE_READ_ONLY flag set, the client library hung if the procedure performed a SELECT that returned an empty result set.