> 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:
* some emalloc
* some efree
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...
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]