agent: subtrees sometimes survive "netsnmp_unregister_handler"

Hi,

I wrote a small agent that registers a few interesting values per 
process, to be queried by any snmp client.

The whole thing monitors "/proc" and,
when a new process appears,
   reads value,
   adds a snmp scalar with (1)
when a process disappears,
   removes the snmp scalar with (2)
otherwise,
   updates the scalar value

(1)

oid = BASE . pid # BASE is constant
reg = netsnmp_create_handler_registration(oid)
netsnmp_inject_handler(reg, netsnmp_create_watcher_info(...))
netsnmp_register_scalar(reg)

(2)

for item = each "watcher" in reg->handler:
   free(item->myvoid) # seems to be neccessary
   item->myvoid = NULL

netsnmp_unregister_handler(reg)


Unfortunately, over time, the process will use up more and more memory, 
but not leak it (as in "valgrind --show-reachable=no").

"valgrind --show-reachable=yes" however has tons of suspicious entries like:

==14027== 31272 bytes in 1303 blocks are still reachable in loss record 
25 of 28
==14027==    at 0x1B905301: calloc (vg_replace_malloc.c:176)
==14027==    by 0x1B9D40B4: netsnmp_create_handler (agent_handler.c:108)
==14027==    by 0x1B9D596D: _clone_handler (agent_handler.c:867)
==14027==    by 0x1B9D59AC: netsnmp_handler_dup (agent_handler.c:592)
==14027==    by 0x1B9D5B13: netsnmp_handler_registration_dup 
(agent_handler.c:673)
==14027==    by 0x1B9CDF1F: netsnmp_subtree_deepcopy (agent_registry.c:126)
==14027==    by 0x1B9CE7E2: netsnmp_subtree_split (agent_registry.c:302)
==14027==    by 0x1B9D0471: netsnmp_subtree_load (agent_registry.c:506)
==14027==    by 0x1B9D0842: netsnmp_register_mib (agent_registry.c:665)
==14027==    by 0x1B9D477D: netsnmp_register_handler (agent_handler.c:248)
==14027==    by 0x1BA01414: netsnmp_register_serialize (serialize.c:43)
==14027==    by 0x1B9FDADE: netsnmp_register_scalar (scalar.c:86)
==14027==    by 0x804B202: ScalarManager::registerInteger(std::string, 
int*, bool, ScalarManager*) (ScalarManager.cpp:197)
==14027==    by 0x804FB13: 
SnmpPersistingValue::SetManagerLink(ScalarManager*) 
(SnmpPersistingValue.cpp:47)
==14027==    by 0x804F83D: 
SnmpPersistingValue::SnmpPersistingValue(ScalarManager*, std::string) 
(SnmpPersistingValue.cpp:24)
==14027==    by 0x8050BED: update_proc_values(ScalarManager&) 
(procagent.cpp:281)
==14027==    by 0x80515B2: main (procagent.cpp:469)

even though I've unregistered all the values at the end.

With ps aux, one can see VSZ growing every time a process spawns (that's 
to be expected) and sometimes not shrinking again when a process dies 
(i.e. when the agent unregisters a scalar) (that's weird).

Now I'm stumped what to do. I tried to debug the problem, and the only 
noteworthy place so far is net-snmp-5.3.1/agent/agent_registry.c:506, 
which reads:

505 /*  Existing subtree contains new one.  */
506 netsnmp_subtree_split(tree1, new_sub->end_a, new_sub->end_len);
507 /* Fall Through */

So the return value of "netsnmp_subtree_split" is _not used at all_. 
Why? Is memory management of the new subtree passed onto the parent or 
something?

A small clean-room test that just registers two scalars and unregisters 
them all the time (without the "/proc" parts) works fine, so it seems to 
be a problem with the tree ordering when random inserts and removes 
happen, only...

Or did I simply forget to call something at unregister time?
(Because all the memory blocks are still reachable, it seems, something 
is holding onto the scalar indefinitely)

Thanks,
   Danny

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

begin:vcard
fn:Danny Milosavljevic
n:Milosavljevic;Danny
org:Fabalabs Software GmbH
adr:;;Honauerstrasse 4;Linz;;4020;Austria
email;internet:[email protected]
title:Research & Development
x-mozilla-html:FALSE
version:2.1
end:vcard