|Hi, While testing PostgreSQL with LeakSanitizer enabled, I found a
memory leak in pg_config. The issue can be reproduced by running:
pg_config --version LeakSanitizer reports 2829 bytes leaked in 47
allocations. The full report is attached as leak_sanitizer.txt. The
relevant allocation stack is: libc.so.6!__GI___libc_malloc(size_t bytes)
(malloc.c:3288) pg_malloc_internal(size_t size, int flags)
(src/common/fe_memutils.c:36) palloc(Size size)
(src/common/fe_memutils.c:123) palloc_mul(Size s1, Size s2)
(src/common/fe_memutils.c:312) get_configdata(const char *my_exec_path,
size_t *configdata_len) (src/common/config_info.c:42) main(int argc,
char **argv) (src/bin/pg_config/pg_config.c:157) Although
get_configdata() uses palloc_array() and pstrdup(), pg_config is a
frontend program. The frontend implementations of palloc() and pstrdup()
ultimately allocate memory using malloc() and strdup(), through
pg_malloc_internal() and pg_strdup(), respectively. These allocations
are not owned by a backend memory context and therefore remain allocated
until they are explicitly freed or the process exits. get_configdata()
allocates the ConfigData array with palloc_array() and allocates its
name and setting strings with pstrdup(). pg_config does not release
these allocations before exiting. This leak is harmless for a
short-lived process, since the operating system releases the memory at
process termination. However, it causes LeakSanitizer failures and adds
noise to sanitizer-based testing. The attached patch adds a helper that
frees every name and setting string and then frees the ConfigData array.
The helper is called on every exit path reached after get_configdata().
After applying the patch, pg_config --version completes without a
LeakSanitizer report. The patch is attached as:
v1-0001-Fix-memory-leak-in-pg_config.patch |
--
Best wishes,
Ivan Kush
Tantor Labs LLC