On 6/27/2022 23:22, Tom Lane wrote:
Karl Denninger writes:
But -- I still have a /lot /of memory out on the heap according to
jemalloc stats that is not being deallocated, and what's worse is that
if I rig the code to call PQfinish and then PQconnect once again I get
/even more /imbalanced allocate/free counts (and the memory use in said
buckets to go with them.)
Hmmm ... I'm not aware of any memory leaks in libpq, but that doesn't
mean there are none. Of course, if you're forgetting to PQclear()
some PGresults, that's not libpq's fault ;-).
Well, yes, which is why I wrapped those calls to make very sure that's
not the case (internal reference count in the code when in "debugging
mode", basically) along with all the uses of escape/unescape (e.g. bytea
fields.) All come back clean on each "round" through which makes it
quite puzzling.
I'll do more digging. I've got wrappers around all memory allocation in
my development libraries that for internal allocations make quite sure
that they're both properly paired and sentinels are on the "bookends" so
if the code does smash something it catches it, and there's nothing
being flagged; the arena, as my code sees it from what it allocated and
the calls it made to libpq, are empty when it comes back as it should
be. Obviously there's leakage somewhere but at this point I'm quite
certain its not in my code itself (its certainly possible FastCGI's lib
has a problem somewhere since it has to construct the environment from
the web server's CGI call for each call to the application, each of
those is distinct, and if something goes wrong there it will leak like
crazy since each of those constructs is unique and then must be properly
released when that call is complete.)
The obvious question, given the warnings in the FastCGI library: Does
libpq /modify /the process environment?
No. At least, I see no setenv() calls in it, and I think that it'd
be pretty unfriendly for a library to do that to its host application.
In this case it would be fatal if that was to happen since the
environment is synthetic and different on each call; if any part of the
environment gets modified then the release by the caller will either
leak or, possibly, result in a SEGV.
A quick grep implies that indeed it may in
backend/libpq/auth.c at least,
backend/libpq is unrelated to interfaces/libpq. (I've seen hints
that they arose from a common code base, but if so, that was a
few decades and a lot of rewrites ago.)
regards, tom lane
Gotcha. It wasn't clear that this was or wasn't implicated and I'm
digging for potential sources, thus the question.
Thanks.
--
Karl Denninger
k...@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
