Karl Denninger <karl@xxxxxxxxxxxxx> 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.)
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.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.
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.
<<attachment: smime.p7s>>
