Hello,
I have identified a memory leak the ip4_map function of
src/plugins/ip4_map.c. I am using the 21.10 release.
Enabling memory trace of the main-heap via the debug CLI and backtracing
with gdb both point to all the leaked memory being allocated from the
vec_add1(buffer0,pi0) macro at line 293 of ip4_map.c. In tests it is
leaking approximately 50 bytes for every packet passing through this
function (invariant on packet size).
Here is an extract of the relevant code:
exit:
/* Send fragments that were added in the frame */
if (free_original_buffer0)
{
vlib_buffer_free_one (vm, pi0); /* Free original packet */
}
else
{
vec_add1 (buffer0, pi0); <<<< leak is here on line 293
}
frag_from0 = buffer0;
frag_left0 = vec_len (buffer0);
while (frag_left0 > 0)
{
while (frag_left0 > 0 && n_left_to_next > 0)
{
u32 i0;
i0 = to_next[0] = frag_from0[0];
frag_from0 += 1;
frag_left0 -= 1;
to_next += 1;
n_left_to_next -= 1;
vlib_get_buffer (vm, i0)->error =
error_node->errors[error0];
vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next,
i0, next0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
vlib_get_next_frame (vm, node, next_index, to_next,
n_left_to_next);
}
vec_reset_length (buffer0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
I must admit I do not fully understand exactly what this code is doing,
but I am suspicious of the use of 'vec_reset_length' macro. I have
looked at the definition of this and it appears that although this sets
the length of the vector back to zero (if the pointer is non-zero), it
does not release any memory that may have been allocated. Do we not
need a call to 'vec_free' somewhere?
Regards,
Ben.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20496): https://lists.fd.io/g/vpp-dev/message/20496
Mute This Topic: https://lists.fd.io/mt/87095064/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
