#2066 table helper leaks memory from variable names

closed
nobody
agent (1103)
5
2012-11-08
2009-07-16
No

netsnmp_table_build_oid_from_index allocs memory for a variable name that never seems to be freed.
Valgrind output:
==20263== 20,453 bytes in 181 blocks are definitely lost in loss record 121 of 131
==20263== at 0x4821259: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==20263== by 0x1AF629: snmp_clone_mem (snmp_client.c:287)
==20263== by 0xC8D34: netsnmp_table_build_oid_from_index (table.c:842)
==20263== by 0x1A86DC: _container_table_handler (table_container.c:504)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC9B88: table_helper_handler (table.c:619)
==20263== by 0xA5487: netsnmp_call_next_handler (agent_handler.c:435)
==20263== by 0xC1E48: netsnmp_bulk_to_next_helper (bulk_to_next.c:116)
==20263== by 0xA4C66: netsnmp_call_handlers (agent_handler.c:435)
==20263== by 0x9427D: handle_var_requests (snmp_agent.c:2542)
==20263== by 0x95477: handle_getnext_loop (snmp_agent.c:2982)
==20263== by 0x982B7: netsnmp_handle_request (snmp_agent.c:3134)
==20263==

Currently that whole allocation is a waste of time anyway, since name_loc is always big enough
to contain the name (someone might want to fix that comment above the name_loc in snmp_api.h
BTW). So don't do it.

Discussion

  • Dave Shield
    Dave Shield
    2009-12-01

    Thanks for the bug report!
    We've fixed the problem in the 5.2.x, 5.3.x
    and 5.4.x code branches and the main development
    tree, so it should be fixed in future releases
    of the Net-SNMP package.

     
  • Dave Shield
    Dave Shield
    2009-12-01

    There's actually a library routine which handles the task of setting the name of a varbind (including taking care of memory allocation/release). So I've tweaked the helper to use that instead.
    SVN revision 17858

    I've also updated the comment for 'name_loc' that you mentioned (SVN revision 17859)