Hello. We are using Confd 3.1 for linux on x86_64, release 26249 (Dec 2009) and are experiencing memory leaks associated with accessing configuration or statistical information from an SNMP server. We do not see this behavior when using NETCONF. This appears to be occurring in the callback API in which SNMP is walking through the configuration tree.
hello,
this feels like very ancient version to reasonably debug or try to address 
There must have been possibly many many updates/fixes to possibly related areas either in ConfD directly or in southbound/northbound APIs.
Can you elaborate a bit on where and how did you identify the leaks? It’s bit unclear to me as you mention “callback API” - that i personally think about in connection with various confd-lib apps/implementations, not ConfD itself.
Sorry for the confusion. It is libconfd, not confd itself, which is causing the leak. We have a management application which links to libconfd, in which we noticed the leak after accessing configuration and statistical information from an SNMP server. We instrumented this application using gcc sanitizer and suspect that the leaks which were not caught by the sanitizer were occurring inside libconfd.
got it, thanks for clarification.
I do not use/know the gcc sanitizer, thus it’s possible that this is also covered in similar/same manner… I typically use Valgrind’s memcheck tool to clear any potential leaks in app that uses confd_lib.
One of tiny pitfalls that sometime can cause issues is implementation of callbacks, are “expectations” in the code… It is possible that NETCONF vs SNMP has a tiny bit different order of invocation of callbacks, or some callbacks are invoked e.g. more times. Not sure if you already covered this step, but try checking that there are no mem leaks or uninitialized items in Valgrind trace for the app after executing your scenario…
Using the structs confd_value_t and/or confd_hkeypath_t in callbacks can leave some items hanging when binary/str types are handled (missing complementary confd_free_value() / confd_free_hkeypath() in callback code)…
In the end, it might show that the leak indeed happens in lib, but valgrind should help navigate to exact point and identify the problem. (edit: as confd_lib is distributed with source code, worst case, it might be possible to then address the potential bug if needed/possible in lib)
Thank you. We initially tried using Valgrind but ran into some issues hence switched to gcc sanitizer but we will give another look at Valgrind.