> Right, sorry, more precisely, by setting them to pemalloc/pefree they
> result in calling malloc/free anyway. Not a direct mapping of course.
> But I think we have beaten this one to death. Since PHP just calls
> malloc/free anyway and the wrapper layer is causing problems, simply
> removi
On Fri, 23 Apr 2004, Andrei Zmievski wrote:
> On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> > You mean they are not generic memory alloc functions? I know that. But
> > they map to malloc/free which is the important point here.
>
> The global variables pcre_malloc and pcre_free initial
On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> You mean they are not generic memory alloc functions? I know that. But
> they map to malloc/free which is the important point here.
The global variables pcre_malloc and pcre_free initially
contain the entry points of the standard malloc
On Fri, 23 Apr 2004, Andrei Zmievski wrote:
> On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> > 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 wrapper
On Fri, 23 Apr 2004, Rasmus Lerdorf wrote:
> 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 PC
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> 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 an
i'm pretty sure it does, it has a compiled regex cache that uses it, i
think.
-sterling
On Apr 23, 2004, at 7:11 AM, Andi Gutmans wrote:
At 10:05 AM 4/23/2004 -0400, Ilia Alshanetsky wrote:
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> I know what you were talking about. I was contemplating of making the PCRE
> library use emalloc/efree (a completely different issue), but arrived at
> the conclusion that it wouldn't work because of the compiled regex caching
> we do.
> *A completely diff
I know what you were talking about. I was contemplating of making the PCRE
library use emalloc/efree (a completely different issue), but arrived at
the conclusion that it wouldn't work because of the compiled regex caching
we do.
*A completely different issue*!!!
Andi
At 08:09 AM 4/23/2004 -07
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 so
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 (
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 PH
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 d
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
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.
Andi
At 07:37 AM 4/23/2004 -0700, Rasmus Lerdorf wrote:
I don't underst
I don't understand why this would have to be in RSHUTDOWN. We are talking
about an Apache restart here so MSHUTDOWN should be sufficient.
-Rasmus
On Fri, 23 Apr 2004, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory man
At 10:05 AM 4/23/2004 -0400, Ilia Alshanetsky wrote:
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory manager to prevent memory leaks and I think
> this is one of PHP's most important features. I
On April 23, 2004 10:01 am, Andi Gutmans wrote:
> I think changing back to malloc/free on RSHUTDOWN is a better solution.
> After all, we use our memory manager to prevent memory leaks and I think
> this is one of PHP's most important features. I don't trust third party
> extensions :)
The php_pcr
I think changing back to malloc/free on RSHUTDOWN is a better solution.
After all, we use our memory manager to prevent memory leaks and I think
this is one of PHP's most important features. I don't trust third party
extensions :)
Andi
At 11:02 AM 4/22/2004 +0100, Joe Orton wrote:
This fixes #
On Thu, Apr 22, 2004 at 11:02:18AM +0100, Joe Orton wrote:
> This fixes #121454: the pcre extension should not change the global
> allocation callbacks for pcre.
Oops, wrong bug and even wrong bug database. I meant #27810.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
This fixes #121454: the pcre extension should not change the global
allocation callbacks for pcre.
PCRE is used inside httpd and may be used by modules other than PHP too;
having these modules use PHP allocation functions doesn't seem at all
sensible, and could mess up the memory limit accounting
21 matches
Mail list logo
