Skip to content
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

Potential race condition on socket open/send (discovered on M1) #325

Open
n-hutton opened this issue Nov 10, 2022 · 0 comments
Open

Potential race condition on socket open/send (discovered on M1) #325

n-hutton opened this issue Nov 10, 2022 · 0 comments
Labels

Comments

@n-hutton
Copy link

Hello,

I am finding that I have the following race condition:

in server/connectors/unixdomainsocketserver.cpp we have:

bool UnixDomainSocketServer::InitializeListener() {
...
  // Set to non-blocking mode
  fcntl(this->socket_fd, F_SETFL, FNDELAY);

So a non blocking socket is created.

Later, a connection is opened when I send data to it, and this function is called:

void UnixDomainSocketServer::HandleConnection(int connection) {
  string request, response;
  StreamReader reader(DEFAULT_BUFFER_SIZE);
  reader.Read(request, connection, DEFAULT_DELIMITER_CHAR);
...
  close(connection);

The read is as following:

bool StreamReader::Read(std::string &target, int fd, char delimiter) {
  ssize_t bytesRead;
  do {
    bytesRead = read(fd, this->buffer, buffersize);
    if (bytesRead < 0) {
      return false;
    } else {
      target.append(buffer, static_cast<size_t>(bytesRead));
    }
  } while (memchr(buffer, delimiter, bytesRead) ==
           NULL); //(target.find(delimiter) == string::npos && bytesRead > 0);

  target.pop_back();
  return true;
}

So what happens is that if the HandleConnection call is executed fast enough, the client has not yet sent any data. Since the socket is non-blocking, the streamreader read returns -1, and the request string will be an empty string. The method then closes the connection, causing an error for the client who is trying to send data.

The current best solution I have to this is to increase the timeout in the handler dispatch. However, it would be better I think if either the socket was blocking, or the return value from the stream reader was utilized in order to detect this case.

@cinemast cinemast added the bug label Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants