[PATCH] Memory leak in pg_config
Hi,
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
Example:
```
$ pg_config --cc
clang
=================================================================
==14521==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 368 byte(s) in 1 object(s) allocated from:
#0 0x55de20d161d9 in malloc (/usr/bin/pg_config+0xf81d9)
[...]
SUMMARY: AddressSanitizer: 2610 byte(s) leaked in 47 allocation(s).
```
The leaked memory is part of the `configdata` array which isn't freed before
exiting. It doesn't have any long term impact but it's annoying.
A similar thing happens in the `pg_config` SQL function. Since the memory
will be released at the end of the transaction, releasing it is optional but
I've done it anyway.
I'm attaching a the patch with the changes.
Greetings,
Greetings,
--
Raúl Marín Rodríguez
carto.com
Attachments:
configdata_leak-v1.patchtext/x-patch; charset=US-ASCII; name=configdata_leak-v1.patchDownload+21-2
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
TBH, I do not think we should do anything about this. It has never been
project policy that short-lived programs should free everything before
exiting, and I don't think we should change that. initdb, in particular,
would need a huge amount of work to meet such a policy, and it would
really be entirely wasted effort. Just because you've configured your
tools to enforce an unreasonable policy doesn't make it a reasonable one.
regards, tom lane
On 11/14/18 3:59 PM, Tom Lane wrote:
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.TBH, I do not think we should do anything about this. It has never been
project policy that short-lived programs should free everything before
exiting, and I don't think we should change that. initdb, in particular,
would need a huge amount of work to meet such a policy, and it would
really be entirely wasted effort. Just because you've configured your
tools to enforce an unreasonable policy doesn't make it a reasonable one.
Yeah. Incidentally we had the same discussion about initdb a few days
ago [1]/messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com, and the conclusion was pretty much exactly the same.
[1]: /messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com
/messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services