Programing question regarding FCGI apps (in "C")

From: Karl Denninger <karl_at_denninger.net>
Date: Sun, 26 Jun 2022 23:46:40 UTC
I have an application that has been a "traditional" CGI app for a long 
time and am converting it to use the fcgi-dev "wrapper" under Apache 
along with writing a little program that manages the daemons (so if 
something goes wrong they get restarted with logging to the admin, I can 
issue a kill to all of them to update the code or a restart request, etc.)

What I found is that with that wrapper in use the code runs fine -- but 
it leaks memory.  It is quite complex and uses the libpq library to talk 
to Postgres, but I've never seen problems with libpq leaking memory 
before.  Nonetheless I spent the rather-considerable time to make darn 
sure via wrapper functions that I wasn't leaking memory through 
inappropriate use of malloc/realloc/free or unpaired calls to the libpq 
functions that create allocations, including using wrappers to maintain 
a list of "active" allocations and outstanding requests, checking for 
dangling file handles, pollution of sentinel space in malloc'd memory 
and similar, tossing any discontinuities in the syslog if it finds any.  
The code is clean and when it comes back for the next "accept()" there's 
nothing outstanding.

This implies that either libpq has a problem or the fastcgi wrapper 
library does.  The former I've used a great deal over a long period of 
time (years) and have never had it cause trouble. The application does 
some "straight through" stuff out of cron as well and there I can run 
valgrind against it, which I have and there are no complaints with it 
unable to find any dangling allocations -- albeit not every function 
that is used in serving web requests in that library is used in the cron 
job.

That leaves the fastcgi wrapper library.  There is a caution in there 
about anything that modifies the environment; I removed all the 
setproctitle() calls which I use to identify status and such, and there 
are no calls to setenv or putenv anywhere, nor any attempts to write 
back to any of the environment pointers -- that much I'm quite sure of.

Anyone seen anything like this?  For obvious reasons this is not good 
behavior but tracking it down has proved elusive.

Thanks in advance!

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/