| Bug #37916 | COM_STMT_CLOSE sends ERR packet, but never a success response | ||
|---|---|---|---|
| Submitted: | 7 Jul 2008 8:34 | Modified: | 31 Jul 2008 17:29 |
| Reporter: | Jan Kneschke | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 5.0.51a | OS: | Any |
| Assigned to: | Davi Arnaut | CPU Architecture: | Any |
[7 Jul 2008 13:39]
Reggie Burnett
This is a problem for other connectors too. Namely, Connector/Net makes no attempt to read a result packet for STMT_CLOSE
[9 Jul 2008 10:27]
Konstantin Osipov
Fixed by the patch for Bug#35103, in the same versions as this bug. Documentation note: this could lead to an internal error of a connector. The scenario in which it could reoccur: - automatic reconnect in the connector is on - the physical connection to the server is temporarily lost, and the server closes the connection on timeout - the physical connection is restored, and the connector automatically reconnects - the client application sends mysql_stmt_close, or an analog - the server sends 'no such statement' back, but the connector does not expect a reply, an internal error of the connector occurs. Note, that the client library (C) is not vulnerable to this problem.
[9 Jul 2008 10:27]
Konstantin Osipov
Note, unlike 35103, the fix for this bug is only in 5.1 and 6.0
[31 Jul 2008 17:29]
Paul DuBois
Per discussion with Kostja, this needs no changelog entry.
Description: mysql_stmt_close() says: @note we don't send any reply to this command. But a invalid statement id leads to 10:26:28.889359 recvfrom(9, "P\0\0\1\377\333\4#HY000Unknown prepared statement handler (16777216) given to mysql_stmt_close", 84, 0, NULL, NULL) = 84 How to repeat: send a empty COM_STMT_CLOSE command: 10:26:26.338983 writev(9, [{"\1\0\0\0\31", 5}], 1) = 5 followed by a COM_QUERY COMMAND: 10:26:28.886991 writev(9, [{"\1\0\0\0\1", 5}], 1) = 5 10:26:28.889359 recvfrom(9, "P\0\0\1\377\333\4#HY000Unknown prepared statement handler (16777216) given to mysql_stmt_close", 84, 0, NULL, NULL) = 84 Suggested fix: The obvious fix is: * fix the protocol to provide a proper OK|ERR return for COM_STMT_CLOSE but it looks like logging the ERR only and not send it is the reasonable fix if we don't want to make this a bug in all connectors (which would have to change their handling of COM_STMT_CLOSE responses).