Hugh Wang <hghwng@gmail.com> writes:
> Even if I believe in LeakSanitizer, it's absolutely stupid to ignore the
> recommendations from an experienced developer. To really make sure that there's
> memory leak, I verified the leak with gdb. When ProcessConfigFile is entered, I
> set a breakpoint to print guc_strdup's return value ($rax) in
> set_config_sourcefile. I also set a breakpoint on free to print the argument
> ($rdi). To sum up: for any returned pointer ofguc_strdup, if a
> corresponding free
> cannot be found, then we can confirm that there's a leak.
[ shrug... ] Nonetheless, your analysis is faulty, because it's
experimentally demonstrable that there is no leak. I just left
a backend run for quite some time, hitting it with a stream of
SIGHUPs, and for good measure having it read the pg_file_settings view
over and over so that the show_all_file_settings code path is being
exercised as well. By now, if either of those code paths was leaking
even one single byte per execution, I could see the difference in "top".
But the process memory size is not moving.
I speculate that you may be confusing the transient ConfigVariable
data structures with the non-transient GUC storage (struct config_generic
and its overlays). The former data structure, including attached strings
such as filenames, is palloc'd in a short-lived memory context and we
get rid of it by dropping the context. The actual GUC storage is malloc'd
so we have to take care to free() any string we replace. As far as I can
tell, we do. set_config_sourcefile certainly does so.
regards, tom lane
