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.
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/0012339c-0ea8-43f6-93e8-33c3ceca0bbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
