Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:9484 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67783 invoked by uid 1010); 22 Apr 2004 10:02:20 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 67695 invoked from network); 22 Apr 2004 10:02:20 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by pb1.pair.com with SMTP; 22 Apr 2004 10:02:20 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3MA2JFe003491 for ; Thu, 22 Apr 2004 06:02:19 -0400 Received: from radish.cambridge.redhat.com (radish.cambridge.redhat.com [172.16.18.90]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3MA2Jp26975 for ; Thu, 22 Apr 2004 06:02:19 -0400 Received: from radish.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by radish.cambridge.redhat.com (8.12.10/8.12.7) with ESMTP id i3MA2Ic3029201 for ; Thu, 22 Apr 2004 11:02:18 +0100 Received: (from jorton@localhost) by radish.cambridge.redhat.com (8.12.10/8.12.10/Submit) id i3MA2IUn029200 for internals@lists.php.net; Thu, 22 Apr 2004 11:02:18 +0100 Date: Thu, 22 Apr 2004 11:02:18 +0100 To: internals@lists.php.net Message-ID: <20040422100218.GB23874@redhat.com> Mail-Followup-To: internals@lists.php.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [PATCH] fix pcre global variable abuse From: jorton@redhat.com (Joe Orton) 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 */