On Fri, 23 Apr 2004, Andi Gutmans wrote: > At 07:49 AM 4/23/2004 -0700, Rasmus Lerdorf wrote: > > > > 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. > > Never mind. I don't feel like explaining myself a thousand times :) If > you'd have read what I wrote you would have seen that I wasn't saying that > we're using emalloc/efree (and thus the memory manager) today. > I was talking about the PCRE library and not the PCRE extension. But in any > case, as PCRE is caching compiled regexes in between requests I don't think > we can make the library use emalloc/efree. > Thus, it seems that the only option is to set the callbacks to malloc/free.
I guess I have no idea what you are talking about. The bug we are discussing is that the PCRE extension registers pemalloc/pefree as the cache malloc/free functions. On a restart these PHP wrappers go away and we crash when another module hits PCRE while PHP is unloaded. It is as simple as that. There is no memory manager issue anywhere in this bug. As far as I can tell you suggested to reset the pemalloc/pefree hook in the RSHUTDOWN and I simply pointed out that MSHUTDOWN would be sufficient if we wanted to keep using the wrapper. Granted, that would mean other modules using PCRE would be using PHP's wrappers for some reason which would technically work. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
