Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9498 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92044 invoked by uid 1010); 23 Apr 2004 14:01:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 91950 invoked from network); 23 Apr 2004 14:01:25 -0000 Received: from unknown (HELO mail.zend.com) (192.117.235.230) by pb1.pair.com with SMTP; 23 Apr 2004 14:01:25 -0000 Received: (qmail 8825 invoked from network); 23 Apr 2004 14:01:24 -0000 Received: from localhost (HELO AndiNotebook.zend.com) (127.0.0.1) by localhost with SMTP; 23 Apr 2004 14:01:24 -0000 Message-ID: <5.1.0.14.2.20040423170041.01fdc1f0@127.0.0.1> X-Sender: andi@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 23 Apr 2004 17:01:21 +0300 To: Joe Orton ,internals@lists.php.net In-Reply-To: <20040422100218.GB23874@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] [PATCH] fix pcre global variable abuse From: andi@zend.com (Andi Gutmans) References: <20040422100218.GB23874@redhat.com> 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 #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 presumably. > >The cause of #121454 is that during a restart, libphp4.so is unloaded >from memory, but the global variable pcre_malloc is left pointing at >php_pcre_malloc; so when httpd uses pcre, it all goes boom. > >Alternative fix might be to use a shutdown function in the extension >which does "pcre_malloc = malloc; pcre_free = free;" but I think it's >wiser just to stay well clear of the issue. > >--- php-4.3.6/ext/pcre/php_pcre.c.pcrealloc >+++ php-4.3.6/ext/pcre/php_pcre.c >@@ -47,20 +47,6 @@ > > ZEND_DECLARE_MODULE_GLOBALS(pcre) > >- >-static void *php_pcre_malloc(size_t size) >-{ >- return pemalloc(size, 1); >-} >- >- >-static void php_pcre_free(void *ptr) >-{ >- if (ptr) >- pefree(ptr, 1); >-} >- >- > static void php_free_pcre_cache(void *data) > { > pcre_cache_entry *pce = (pcre_cache_entry *) data; >@@ -107,14 +93,6 @@ > REGISTER_LONG_CONSTANT("PREG_SPLIT_OFFSET_CAPTURE", > PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT); > REGISTER_LONG_CONSTANT("PREG_GREP_INVERT", PREG_GREP_INVERT, > CONST_CS | CONST_PERSISTENT); > >- pcre_malloc = php_pcre_malloc; >- pcre_free = php_pcre_free; >- >-#ifdef NO_RECURSE >- pcre_stack_malloc = php_pcre_malloc; >- pcre_stack_free = php_pcre_free; >-#endif >- > return SUCCESS; > } > /* }}} */ >@@ -548,7 +526,7 @@ > } > } > >- php_pcre_free((void *) stringlist); >+ pcre_free((void *) stringlist); > } > } > else { /* Failed to match */ > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php