"External" memory leaks are not detected by GitLab CI

If named's memory use grows over time, but that growth is reflected in the "in use" statistics of libisc memory contexts, tracking down the source of such growth is a matter of time. However, not all memory that named uses is contained in libisc memory contexts: every linked shared library might also perform its own memory allocations. If those are not cleaned up properly, core dump examination is no good for tracking them down unless the "needle" (i.e. what we are looking for) is known beforehand, which is rarely the case.

The most notable example of this type of problem are memory leaks which are specific to FreeBSD - these are usually caused by the fact that libthr (the POSIX Threads implementation FreeBSD currently uses) allocates memory on the heap for most of its objects upon their creation. If such an object is a part of an often-recycled data structure used by named (e.g. a socket), missing destructors can lead to memory exhaustion issues over time, but only on specific operating systems. This has already happened at least twice so far.

Finding a method of detecting "external" memory leaks in GitLab CI should prevent such problems from reoccurring in the future.

See #3051 (closed)