On Fri, 23 Apr 2004, Andi Gutmans wrote: > At 07:43 AM 4/23/2004 -0700, Rasmus Lerdorf wrote: > >On Fri, 23 Apr 2004, Andi Gutmans wrote: > > > If we were to use emalloc/efree and PHP would leave these at the end of the > > > request, then some other Apache module which uses PCRE would be using PHP's > > > emalloc/efree. I don't think it has anything to do with Apache restart. > > > >Which should be fine since the PHP function is there and just maps to > >malloc/free anyway. The problem on a reload is that PHP gets unloaded so > >any other module that uses pcre while PHP is unloaded will crash. So I > >think the specific bug we are talking about is very much related to an > >Apache restart. Of course, the way it is written, it is silly for it to > >use the pemalloc wrapper. > > You didn't understand what I'm saying. If we were to use emalloc/efree > (which we don't but we should if possible) and if we wouldn't replace them > with malloc/free on RSHUTDOWN, then some other Apache module which handles > the next request (mod_perl for example) would call our emalloc/efree. As > the memory manager wouldn't be initialized this would most likely crash.
But it always uses the persistent flag, so where is the memory manager issue? pemalloc(foo,1) is going to map straight to malloc(foo) is it not? The way ext/pcre works is that it uses emalloc/efree for the non-persistent allocs directly but it registers pemalloc/pefree for the persistent memory handling. The correct fix here is to just use malloc/free for the persistent stuff. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
