-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Socket.read(...) unexpectedly returns 0 #79
Comments
This is still an issue and the potential fix still works, just ran into it attempting to read 90k bytes from an android client. |
Are you sure the socket is blocking? EWOULDBLOCK should only return for a non-blocking socket. |
Yes, the socket is definitely configured to be blocking ( EWOULDBLOCK is being raised in the SSL layer upon reading at least one byte but fewer bytes than requested. Excerpts from SSLService.swift:
|
On a "blocking" client socket,
Socket.read(into data: inout Data)
sometimes unexpectedly returns 0, even when the remote connection has not closed (Socket.remoteConnectionClosed == false
).This only reproduces on macOS.
This only happens using SSL/TLS (BlueSSLService).
Environment
Client on macOS (10.14.5), using Swift 5.0.1 (Xcode 10.2.1), BlueSocket 1.0.47, BlueSSLService 1.0.47. (The client software is a Swift database driver for the PostgreSQL database.)
Server is a PostgreSQL database server (PostgreSQL 10.9) running on Ubuntu 18.04 LTS.
The issue reproduces in multiple client and server environments. The issue reproduces more consistently on "distant" servers (e.g. running on AWS EC2 or Linode) than on "nearby" servers (e.g. on the same LAN as the client).
(I tried to reproduce the problem with the client running against a simple standalone Swift server, but was not able to reproduce the problem that way. So I'm not able to provide code for a standalone reproducible test case.)
Analysis
The Xcode debugger was used to analyze why
Socket.read(...)
is returning 0.In SSLService.swift, the function
sslReadCallback(...)
is the callback function forSSLRead
. In line 1406,sslReadCallback(...)
invokes theread(...)
system call, which sometimes returns fewer bytes than requested.When this occurs,
sslReadCallback(...)
returnserrSSLWouldBlock
. When control returns to theSSLRead
call site (SSLService.swift, line 687), we see:(I suspect
processed == 0
becauseSSLRead
requires its callback to return all requested bytes beforeSSLRead
decrypts the received message.)SSLService.recv(...)
then returns -1 witherrno
set toEWOULDBLOCK
(line 695).Socket.readDataIntoStore()
detects this error and returns 0 (Socket.swift, line 3589).Socket.read(...)
then returns 0 (line 2772).Potential fix
In the
sslReadCallback(...)
function, I changed the "read" system call to requestMSG_WAITALL
.Line 1406 changed from:
to:
MSG_WAITALL
forces the socket read to block until the requested number of bytes are available (or an error occurs).This one-line change appears to resolve this issue. However, I don't have sufficient familiarity with BlueSocket/BlueSSLService internals (or low level network programming, for that matter) to assess whether it would cause other problems.
Please let me know if there is other information I can provide.
[edited to correct typo]
The text was updated successfully, but these errors were encountered: