I'm seeing a memory leak in 5.7.3 on FreeBSD related to udpEndpointTable.
Regretfully I'm unable to find the cause, and have no patch to propose.
Valgrind report, after 10 snmpwalks of mib-2:
==72602== 57,240 bytes in 45 blocks are definitely lost in loss record 310 of 310
==72602== at 0x4C1DC7B: calloc (vg_replace_malloc.c:726)
==72602== by 0x518A0C9: udpEndpointTable_allocate_rowreq_ctx (udpEndpointTable_interface.c:642)
==72602== by 0x518B72E: udpEndpointTable_container_load (udpEndpointTable_data_access.c:252)
==72602== by 0x518ADF3: _cache_load (udpEndpointTable_interface.c:947)
==72602== by 0x4E3C31F: _cache_load (cache_handler.c:700)
==72602== by 0x4E3BD5F: netsnmp_cache_check_and_reload (cache_handler.c:542)
==72602== by 0x4E3C197: netsnmp_cache_helper_handler (cache_handler.c:638)
==72602== by 0x4E51F34: netsnmp_call_handler (agent_handler.c:526)
==72602== by 0x4E52453: netsnmp_call_next_handler (agent_handler.c:640)
==72602== by 0x4E44B8E: table_helper_handler (table.c:712)
==72602== by 0x4E51F34: netsnmp_call_handler (agent_handler.c:526)
==72602== by 0x4E522F5: netsnmp_call_handlers (agent_handler.c:611)
(BTW, I have already applied patches from other memory-leak bugs: 2063, 2387 and 2674. That last one is closed, but it looks like the fix did not make it to 5.7.)
Aha!
udpEndpointTable_container_load() is neglecting to check the return value of CONTAINER_INSERT(). The attached patch satisfies valgrind.
(Although snmpd did print several "error on subcontainer 'udpEndpointTable'" errors, I failed to see them in the firehose-spam of "Connnection from UDP" messages. Perhaps the default allow_severity should be changed?)
Thanks for finding this. It has been applied to the active branches.