This got addressed in https://github.com/grpc/grpc/pull/12353, thanks!
On Wednesday, August 30, 2017 at 10:22:02 PM UTC-7, [email protected] wrote: > > 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/6ecdf47c-df39-4539-ae45-d128addece24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
