webscalesqlclient cannot connect to mysql db on OSX

[wjywbs]

Running the following script from php.net with hhvm master on Mac, I get Warning: mysql_connect(): Lost connection to MySQL server at 'reading authorization packet', system error: 35 in mysql.php on line 2.

<?php
$link = mysql_connect('localhost', 'user', 'pass');
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);

This is a temporary fix after basic debugging:

diff --git a/sql-common/client.c b/sql-common/client.c
index 23b8fbe..89ec6ef 100644
--- a/sql-common/client.c
+++ b/sql-common/client.c
@@ -3798,6 +3798,7 @@ authsm_read_change_user_result(mysql_authsm_context *ctx)
         DBUG_RETURN(STATE_MACHINE_WOULD_BLOCK);
       }
     } else {
+      usleep(50);
       ctx->pkt_length= (*mysql->methods->read_change_user_result)(mysql);
     }
   }

Link to the same issue in the hhvm project: facebook/hhvm#5558.

[pivanof]

Can you give more information on the problem you see and why you are offering to add sleeping to the client code?

[wjywbs]

This only affects Mac but not Linux. It looks like the packet is not available yet before the sleep. If the sleep is removed, read_change_user_result() will return packet_error and the script will fail to connect to the mysql server with error `Lost connection to MySQL server at 'reading authorization packet', system error: 35.

Adding a sleep is only a temporary fix. A more stable fix is needed for this issue.

https://github.com/webscalesql/webscalesql-5.6/blob/edad0400107c2839ab554af5d7ff3b34217f0bb9/sql-common/client.c#L3823

[wake-up-neo]

The same issue on OSX for mysql/mysqli. PDO connects normally.

[jwatzman]

The source of the bad read and error ultimately comes from here: https://github.com/webscalesql/webscalesql-5.6/blob/75b113fadf6dc9aabfedad559fec7181f03e7ad2/vio/viosocket.c#L125-L131

That block was added as part of the async mysql diff, and doesn't exist upstream. It also looks very wrong to me. My understanding of the surrounding loop is that it attempts to read from a socket, maybe getting some data, and then waiting until more data is available. This process seems like it should be the same whether the socket is blocking or not (and HHVM tends to have nonblocking sockets here, since it sets timeouts in the mysql/mysqli extensions, which cause webscalesql to mark the socket as nonblocking, since the timeout logic is done in vio_socket_io_wait I think). In particular, nonblocking sockets seem more likely to not have data available and need to go into vio_socket_io_wait.

But it's unclear why this seems to mostly (only?) affect OS X...

In any event, that block looks wrong, should it be removed? cc @steaphangreene who wrote it, @chipturner and @darnaut who had some discussion about a close bit of code in viosocket.c on https://reviews.facebook.net/D17031

[jwatzman]

Just proposed https://reviews.facebook.net/D46023 to fix this.