Programing question regarding FCGI apps (in "C")
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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]/