Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
3.3, 3.4
-
None
-
macOS
Description
When server closes the socket during connect phase, on macOS it can happen, that while mysql_real_connect fails, client library returns mysql_error 0.
This should not happen, it confuses the tools , notably mysqltest, that erroneously thinks the connect was successful (see MDEV-33616). mtr suite expects at least 2013 (CR_SERVER_LOST) in such cases.
Gosselin can provide additional details, as he owns a mac. Yet buildbot proves the point - The test main.connect failed on (almost?) every push on mac with following diff
CURRENT_TEST: main.connect
|
--- /Users/ec2-user/buildbot/aarch64-macos/build/mysql-test/main/connect.result 2024-06-10 17:20:48
|
+++ /Users/ec2-user/buildbot/aarch64-macos/build/mysql-test/main/connect.reject 2024-06-11 03:08:55
|
@@ -232,7 +232,7 @@
|
|
# -- Connecting super (2) [should fail]...
|
# -- Establishing connection 'con_super_2' (user: root)...
|
-# -- Error: can not establish connection 'con_super_2'.
|
+# -- Connection 'con_super_2' has been established.
|
|
So there is some code path that does not set mysql_errno in failure case, which so far was not caught on either Windows or Linux (or FreeBSD, not even on AIX) , but on macOS.
It is of course mysqltest bug, that it treated a failed connection as successful, but it would still need error code, CR_SERVER_LOST anything. 0 is not a good error code.