"External" memory leaks are not detected by GitLab CI
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)