[core] Bug in tcp_do_read() in tcp_posix.c?

[tud...@gmail.com]

Hello,

I found this by code inspection when debugging a (potential) memory leak (or at least a huge increase in memory usage) under load.

This section of tcp_do_read() sets up the iovecs for the recvmsg() system call:

  for (i = 0; i < tcp->incoming_buffer->count; i++) {

    iov[i].iov_base = GRPC_SLICE_START_PTR(tcp->incoming_buffer->slices[i]);

    iov[i].iov_len = GRPC_SLICE_LENGTH(tcp->incoming_buffer->slices[i]);

  }

  msg.msg_name = NULL;

  msg.msg_namelen = 0;

  msg.msg_iov = iov;

  msg.msg_iovlen = tcp->iov_size;

  msg.msg_control = NULL;

  msg.msg_controllen = 0;

  msg.msg_flags = 0;

We create one iovec for each of the slices in tcp->incoming_buffer, but then we tell recvmsg() that the number of slices is tcp->iov_size (instead of tcp->incoming_buffer->count). tcp->iov_size is always 1 (it is assigned only once, in grpc_tcp_create()).

This means that we only use the first slice to read into, even though we meant to use all (up to) 4; the other slices end up being saved until the next call in tcp->last_read_buffer.

I don't fully understand the memory allocation consequences of this; at the very least, this messes with the target_length estimates.

Thanks,

-Tudor.

[Ken Payson]

This got addressed in https://github.com/grpc/grpc/pull/12353, thanks!