Re: Libpq question related to allocated resources

Karl Denninger <karl@denninger.net> 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.