php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74290 [mysqlnd] Annoying "mysqli::close(): Couldn't fetch mysqli" warning
Submitted: 2017-03-22 13:22 UTC Modified: 2017-05-14 04:22 UTC
Votes:4
Avg. Score:4.2 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: vedad at kajtaz dot net Assigned:
Status: No Feedback Package: MySQLi related
PHP Version: 7.0.17 OS: FreeBSD 10.1
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2017-03-22 13:22 UTC] vedad at kajtaz dot net
Description:
------------
The following warning is generated by mysqlnd on mysqli::close() call when the server, upon receiving COM_QUIT, closes the connection instead of sending an OK_Packet:

PHP Warning:  mysqli::close(): Couldn't fetch mysqli in ...

According to the MySQL spec, simply closing the connection is perfectly valid:

https://dev.mysql.com/doc/internals/en/com-quit.html

    "response: either a connection close or a OK_Packet"

Therefore, I believe this warning should be removed, as it does not report any unexpected behavior.

One may overcome the issue using the @ operator, or disabling the error reporting for this specific call, but both the warning itself and the workarounds are a waste of CPU resources IMHO.





Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-04-10 08:29 UTC] fjanisze@php.net
-Status: Open +Status: Feedback
 [2017-04-10 08:29 UTC] fjanisze@php.net
Can you provide some details on what server version you're using?
 [2017-04-12 12:51 UTC] vedad at kajtaz dot net
I'm not using a MySQL server, but a closed source MySQL proxy. I can provide a test access if necessary?
 [2017-04-23 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2017-04-24 09:05 UTC] vedad at kajtaz dot net
Hello,

As stated in previous comments, the MySQL proxy in use is MySQL specification-compliant, and I believe the warning should be removed, as it doesn't report any unexpected/un-compliant behavior. What kind of additional feedback is needed?
 [2017-04-24 09:15 UTC] requinix@php.net
-Status: No Feedback +Status: Open
 [2017-05-05 06:13 UTC] fjanisze@php.net
-Status: Open +Status: Feedback
 [2017-05-05 06:13 UTC] fjanisze@php.net
Neither mysqli nor mysqlnd will raise a warning in case of missing OK_packet after a COM_QUIT (mysqli::close()) to the server, there must have been something else ongoing with the server during the COM_QUIT. 

The fact that "I'm not using a MySQL server, but a closed source MySQL proxy" let me think that you closed source version is working differently from the opensource MySQL server, thus it might not be compliant. From our perspective the server behavior is the ground on which we define what is an expected or non expected event.

I had a peek at the server code and attempted to execute some test scenario with debug logging enabled, I dot even see the server sending the packet at all in my local setup and no warning is raised.
 [2017-05-05 14:03 UTC] vedad at kajtaz dot net
You're right, the MySQL server (tested w/Percona 5.6) does not send the OK_Packet upon COM_QUIT and neither does the proxy.

I suspect a script issue (double close) instead. Thanks for investigating and sorry for the noise.
 [2017-05-14 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Sep 26 12:05:52 2022 UTC