# Memory Leak Observed

**URL:** <https://dmap-community.ductus.global/t/memory-leak-observed/3361>\
**Category:** General\
**Created:** [November 2, 2020, 9:58am UTC](https://dmap-community.ductus.global/t/memory-leak-observed/3361 "2020-11-02T09:58:18Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![cohult](https://yyz2.discourse-cdn.com/flex010/user_avatar/dmap-community.ductus.global/cohult/32/221_2.png) [@cohult](https://dmap-community.ductus.global/u/cohult)\
**Post date:** [November 5, 2020, 10:25am UTC](https://dmap-community.ductus.global/t/memory-leak-observed/3361/7 "2020-11-05T10:25:15Z")

</div>

From the ConfD UG (that has been quoted many times before):

> When debugging application memory leaks with a tool like valgrind, it is often necessary to rebuild libconfd from source, since the default build uses a “pool allocator” that makes the stack trace information for memory leaks from valgrind completely misleading for allocations from libconfd. The details of how to do a build that disables the pool allocator are described in the “Application debugging” section of the README in the libconfd source package

…and from the “libconfd source package” README:

> When debugging application memory leaks with a tool like ‘valgrind’, and  
> the stack trace information from ‘valgrind’ indicates that memory  
> allocated by libconfd has not been freed, it is _necessary_ to rebuild  
> libconfd from source, since the default build uses a “pool allocator”  
> that makes the stack trace information for libconfd completely  
> misleading.
> 
> To build a version of libconfd that disables the pool allocator, the  
> environment variable $NO\_FIX\_ALLOC must be set to “yes” before building  
> from a freshly unpacked tar archive - running ‘make clean’ after an  
> earlier build is _not_ sufficient. I.e. proceed as follows:
> 
> 1. Unpack the tar archive.
> 2. Do ‘export NO\_FIX\_ALLOC=yes’ in the shell.
> 3. Build as described above.
> 
> Note that the libconfd performance may be degraded when the pool  
> allocator is disabled - i.e. such a build should only be used for  
> debugging.

---

_[View the full topic](https://dmap-community.ductus.global/t/memory-leak-observed/3361)._