Re: efree/emalloc in sapi

> Generally, the emalloc should be working all the way since > start_memory_manager was called - which means, from engine startup. The > "request cleanup" (freeing all non-persistent memory blocks) happens on > shutdown_memory_manager, which is called from php_request_shutdown, > after calling request shutdown routines for all modules and extensions, > including SAPI request shutdown. > > Giving second look on what I wrote, you code (from what I got from your > description) generally should be safe to use emalloc... Maybe you have > some other problem there? first to tell you what exactly am i doing - a sapi module for a radius server... (i have posted a note a while ago here) the thing is not threaded and there are several processes calling external stuff. i have replaced the exec call to process php files natively. my future plan is to make some checks on file extension and process it both ways but this is not important for my problem. generally the radius server processes two types of requests: - login (query) that goes in a single new process which dies afterwards - accounting - start/alive and stop that is handled sequentially in a single process that never exits my first code used emalloc/efree in the following places: sapi_startup... php_module_startup... * some emalloc php_request_startup php_execute_script php_request_shutdown * some efree php_module_shutdown sapi_shutdown this works fine if called one time (login works ok). if an acct request comes in - the first one works fine and the next one segfaults or infinitely loops in libc's free. the whole thing works fine again if i remove the efree calls. (with a small leak but i am not sure if this isn't some cache) here i conclude that the request_shutdown call is freeing my memory and when i free it again there is a memory mess. after replacing emalloc/efree with malloc/free the code works (with a small leak but i am not sure if this isn't some cache) i know that if i repeatedly execute php scripts from a single process it is better to sapi/module startup once then execute_script and at exit sapi/module shutdown. but i think it shall work both ways only with a performance penalty in my case... b.