Re: SAPI Module Leaking

Well, it is pretty complicated to fix, even though it's been a very long while since I touched this code so I may be wrong. As far as I recall, the TSRM hash tables won't reuse entries that were freed by threads that terminated. Fixing this, especially without hurting performance, may be quite complicated. That said - I'm not sure it accounts for 1KB per request. There could be leaks in other places. At 23:38 21/12/2001, Alex Leigh wrote:

Well, at this point it is only leaking 1k per request; that doesn't "sound" overly complicated to fix. Do you have an idea of what particularly TSRM is leaking, after ts_thread_free() is called? I'd be happy to poke around the code. Alex On 12/21/01 2:38 PM, "Zeev Suraski" <zeev@zend.com> wrote: The way TSRM is written is not designed for servers that don't reuse threads for more than one request, so if that's how it works - you're going to see a growing memory image all the time :I At 22:16 21/12/2001, Alex Leigh wrote:

Ok. I looked at the ISAPI code, and I am now calling ts_thread_free() when the handler exits. This seems to have cleared up the problem

immensely, but

it's still leaking to the tune of ~1k per request. I'll go over my SAPI module again to verify that is not the cause of the 1k leak. Also with php4-20011217120 randomly (13 times in 5000 requests), the page (1k test data with no php script commands) fails to serve. Php writes: Unknown(0) : Warning - Failed opening '/web02/content/_default/_default/k1.php' for inclusion (include_path='.:/usr/local/lib/php') To stdout Alex On 12/21/01 12:52 PM, "Andi Gutmans" <andi@zend.com> wrote:

Check out DllMain() in php4isapi.c. Are you running the thread attach and thread detach code? Andi At 12:43 PM 12/21/2001 -0600, Alex Leigh wrote:

It can do both. In the testing configuration, it is not pooling but destroying the threads. They are created as detached threads, which at

least

on Solaris go away after they terminate; the ones that exit aren't

building

up in the process (I verified this with pstack). I am not specifying an explicit cleanup handler for the threads, if that makes any

difference; they

are exiting normally by returning off the function called in pthread_create().

Does this web server spawn a new thread for each request? Or does it

reuse

its threads? Andi At 12:22 PM 12/21/2001 -0600, Alex Leigh wrote:

I'm sure it's leaking, it'll readily consume a gig of memory and

shows no

signs of slowing down. I originally was calling phpinfo(), but it also

leaks

equally if I just have the php handler serve a page with no php in it. So, yes, it leaks that amount every request and it never frees. The code as I mentioned is a copy of the NSAPI module (nearly

identical),

and it basically does: if (php_request_startup(TSRMLS_C) == FAILURE) {

      return FAILURE;

} ... php_execute_script(&file_handle TSRMLS_CC); php_request_shutdown(NULL); Alex On 12/21/01 10:28 AM, "Zeev Suraski" <zeev@zend.com> wrote:

Are you calling request_shutdown? Also, are you sure it's actually leaking? Does it leak 200-400KB

on each

and every request, or does this rate 'slow down' at some point? Zeev At 18:20 21/12/2001, Alex Leigh wrote:

All - I have written a SAPI module for a new webserver "continuity". The

code is

basically the SAPI code for NSAPI, modified to work with

continuity's API.

Continuity is threaded, based on the pthread libraries. My problem is that each requests that is handled by PHP leaks about 200-400KB. I've gone over the code carefully, and I don't see that

I am

doing (or more importantly, not doing) anything differently than any

of the

other SAPI modules. I have tried php4-4.1.0, as well as the 12/17 cvs snapshot, on both

Linux

and Solaris. I did not configure php with any options other than

that to

include my sapi module "--with-capi". If someone could give me a reference to SAPI documentation (none of

which I

could find), or give me a lead on what my problem might be, I'd

appreciate

it. My SAPI code can be had at http://www.ashpool.com/dist/php4-capi-v200-p1.tar.gz -- Alex Leigh - www.tessier.com - aleigh@tessier.com The difference between theory and reality is that in theory there is no difference. -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail:

php-list-admin@lists.php.net

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail:

php-list-admin@lists.php.net

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net