This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

What commit fixed this?  It's not referenced in the Changelog or NEWS, and http://cvs.php.net/cvs.php/php-src/ext/pcre doesn't show any files have been changed recently.  I assume the commit was made elsewhere, but I don't have the first idea where to look.

Also, Bug #27735 described this exact same issue but was tagged as "Bogus".  Might want to change that...

Hello Devs,
since my original (http://bugs.php.net/bug.php?id=27735) report turned out not to be bogus, please post a proper ressource which fixes exactly _this_ bug.
A lot of people contacted me via mail and asked for a solution.
I think, I speak for a lot of people out there who are not happy with rolling out a dev version from cvs to production systems which is categorized "not for production use"...
Since I was not able to track down which diff fixes only this bug, please post sufficient information for people who are not deep into development...
Maybe the front page is a nice place for that regarding the number of people affected by this bug...
That´s the way things should go...

The exact same issue occurs on Windows as well, but was marked "Bogus":

http://bugs.php.net/bug.php?id=27751

An update to Changelog or NEWS on this bug may be good

The exact same issue occurs on Windows as well, but was marked "Bogus":

http://bugs.php.net/bug.php?id=27751

An update to Changelog or NEWS on this bug may be good

The same issue with ***php5RC1*** !!!
...
- Install apache-2.0.49
- Compile php-5RC1 with PCRE support using apxs
- run apachectl start
- run apachectl restart or apachectl graceful and apache will die

--- Don't work: ---
+apache 2.0.49 +php5.0.0RC1 with pcre = Not OK
+apache 2.0.49 +php4.3.5    with pcre = Not OK

--- works: ---
+apache 2.0.49 +php5.0.0RC1 w/o  pcre = OK
+apache 2.0.49 +php4.3.5    w/o  pcre = OK
+apache 2.0.48 +php5.0.0RC1 with pcre = OK
+apache 2.0.48 +php4.3.5    with pcre = OK

Please REOPEN:
I just tried PHP 4.3.6-RC1 and the crash is still present.  I also run FreeBSD 5.2.1-RELEASE-p4 with Apache 2.0.49.

Also, what commit was supposed to fix this?  Why no mention in NEWS or Changelog?

This bug is also present in PHP-5.0.0RC1, and it is also 
present in the current CVS HEAD for PHP5 (as of 12:00 
EST).

Can we get a comment on this from PHP folks?  We still see this problem with recent versions of PHP (including latest RCs and snaps) and Apache 2.0.49.  We are unable to find the commit Ilia referred to that supposedly fixed this issue.

I look forward to hearing back from you.

--- Don't work: ---
+apache 2.0.49 +php4.3.5   Not OK
--- works: ---
+apache 2.0.49 +php4.3.4   OK
+apache 2.0.49 +comment out(php4.3.5) OK

OS is Redhat9.apache is installed from sorse.

It defently doesnt work on:

FreeBSD 4.8, apache 2.0.49, php4-4.3.5

/thomas

Can we get an update on this? The bug is marked as 
'closed', but there's no documentation on how this was 
fixed in CVS, and I can personally attest that it's not 
fixed in CVS HEAD for php5.

Try the latest snapshot.  It should be fixed.

Why are you telling it is fixed? It is not :-((( !!!
To restart apache with mod_php you have to "kill" shared memory area with "ipcrm -m"

I experience the exact same problem under FreeBSD 5.2.1 and also under Windows XP (just testing my scripts on this platform, I don't use Windows as a server).

Why don't the developers give details on exactly how this bug was fixed in CVS? (If it was really fixed at all. Some people suggest that it was not.) First they labeled this bug as 'bogus' when in fact it was not. Now they say it has been fixed but don't give out any deatils. Is this the way open source projects work?? If it's going to be like this, then I must say open source developers are no better than Microsoft!! Maybe they are just ashamed of a lame bug in their source and trying to keep this as a secret? What's happening here??

I'm running  Apache/2.0.48 (Unix) mod_perl/1.99_13 Perl/v5.8.2 PHP/4.3.5 and I get this same crash when I try to restart Apache gracefully.

My PCRE info:

PCRE Library Version 	4.5 01-December-2003

Is everyone else using mod_perl?

Peace...

I'm seeing this same (or similar) problem with Apache 2.0.49 and PHP-4.3.6RC3 on Linux.  I'm trying to test mod_perl-1.99-13 with Apache 2.0.49 and PHP-4.3.6RC3 and I get this:

t/perl/hash_attack......................ok                                   
t/perl/ithreads.........................ok                                   
t/perl/ithreads2........................ok                                   
t/preconnection/note....................ok                                   
t/protocol/echo.........................ok                                   
t/protocol/echo_filter..................ok                                   
t/vhost/config..........................ok                                   
All tests successful, 4 tests skipped.
Files=174, Tests=1076, 277 wallclock secs (158.69 cusr + 18.64 csys = 177.33 CPU)
[warning] server linux:8529 shutdown
[warning] port 8529 still in use...
......done
[  error] oh golly, server dumped core 
[  error] for stacktrace, run: gdb /usr/local/apache-2.0.49/bin/httpd -core /home/tom/mod_perl-1.99_13/t/core.17388

So, I run the gdb command above and get this backtrace:

(gdb) bt
#0  0x40300860 in ?? ()
#1  0x08071601 in regex_cleanup (preg=0x864c9c8) at util.c:258
#2  0x4011da0d in run_cleanups (cref=0x80a2f28) at apr_pools.c:1951
#3  0x4011d14d in apr_pool_destroy (pool=0x80a2f18) at apr_pools.c:730
#4  0x4011d208 in apr_pool_destroy (pool=0x80a0f10) at apr_pools.c:727
#5  0x0806efc3 in destroy_and_exit_process (process=0x864c9c8, process_exit_value=140822984) at main.c:208
#6  0x0806fc33 in main (argc=9, argv=0xbfffdb44) at main.c:624
#7  0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) 

If I remove the loading of the PHP module in Apache 2.0.49, the mod_perl_1.99-13 test runs cleanly and no core files get generated.  :(

Peace...

I just tried the latest php5 snapshot. Problem still 
present.

Is it only fixed in php4 cvs?

Can you tell us what the problem actually is? There's 
still no documentation of it in Changelog or in NEWS.

I also tried the latest php4 snapshot, as well as the 
latest php4 release candidate, and CVS HEAD for both 
php4-STABLE and php5.

None of them worked. This bug is not fixed in CVS, in 
snaps, or anywhere. It's not documented as being fixed, 
and the problem is still there.

I finally got fed up and took ext/pcre from php-4.3.4 
and used that instead of what you shipped with php
-5.0.0rc1, and that works fine.

NOT fixed with php-4.3.6

I just tried this and it isn't fixed with PHP 4.3.6 either.

Here's the diffs between the old (working) version of PCRE and the new (broken) version of PCRE. Note changes in memory allocation code, which I believe is causing the problem:

Note: 4.3.4 works (1.29.2.3, 1.132.2.10)
Note: 4.3.5 is broken (1.29.2.5, 1.132.2.16)

diff pcre.4.3.4/config.m4 pcre.4.3.5/config.m4
2c2
< dnl $Id: config.m4,v 1.29.2.3 2003/06/29 00:08:29 andrei Exp $
---
> dnl $Id: config.m4,v 1.29.2.5 2003/12/16 22:14:55 andrei Exp $
Only in pcre.4.3.4: pcrelib
diff pcre.4.3.4/php_pcre.c pcre.4.3.5/php_pcre.c
19c19
< /* $Id: php_pcre.c,v 1.132.2.10 2003/09/12 01:32:38 sniper Exp $ */
---
> /* $Id: php_pcre.c,v 1.132.2.16 2004/02/01 19:56:16 moriyoshi Exp $ */
108a109,117
> 
> 	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
> 	
124,133d132
< /* {{{ PHP_RINIT_FUNCTION(pcre) */
< static PHP_RINIT_FUNCTION(pcre)
< {
< 	pcre_malloc = php_pcre_malloc;
< 	pcre_free = php_pcre_free;
< 	
< 	return SUCCESS;
< }
< /* }}} */
< 
177c176
< 	while (isspace((int)*p)) p++;
---
> 	while (isspace((int)*(unsigned char *)p)) p++;
186c185
< 	if (isalnum((int)delimiter) || delimiter == '\\') {
---
> 	if (isalnum((int)*(unsigned char *)&delimiter) || delimiter == '\\') {
351c350
< 	int				 flags;				/* Match control flags */
---
> 	long				 flags;				/* Match control flags */
365c364
< 	int				 start_offset = 0;	/* Where the new search starts */
---
> 	long				 start_offset = 0;	/* Where the new search starts */
432c431
< 		int name_cnt, name_size, ni = 0;
---
> 		int name_cnt = 0, name_size, ni = 0;
1394a1394,1398
> 			case '\0':
> 				*q++ = '\\';
> 				*q++ = '0';
> 				break;
> 
1526c1530
< 	PHP_RINIT(pcre),
---
> 	NULL

You might want to take a look at...

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17055

This seems very similar.

Apache 2.0.49, mod_ssl (OpenSSL 0.9.7d), PHP 4.3.6, mod_perl 1.99_13, mod_delfate (zlib 1.1.4), perl 5.8.3

Built with VS.NET 2002 under Win2k, SP4 (except PHP 4.3.6 -- official binary)

After 'net stop Apache2'...

Apache.exe - Application Error

The instruction at "0x77f92373" referenced memory at "0x00000010". The memory could not be "written".


We do have a workaround for this problem:
set "LogLevel" under httpd.conf from "warn" to "error"
(this only works for a select set of versions of Apache and PHP)

If Apache2 is not started with "-D SSL" and PHP 4.3.6 is used (over 4.3.5), the app error does not happen.

Hopefully fixed in php port with this patch:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3apcre%3a%3aphp_pcre.c?rev=1.1&content-type=text/x-cvsweb-markup

Bless you -- the FreeBSD port works flawlessly for me now.

Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl
graceful'. Which is a kill for logrotation! Everything was fine untill
4.3.5 came along. Changing back to 4.3.4 solves the problem.
I have tried recompiling apache etc. Nothing helps.
Gracefully restarting apache gives the following in the error-logs:
[Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing
restart
[Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error
detected in the parent process

And apache has to be restarted once more to get it running.

Here is the patch to fix it on php-4.3.6:

--- ext/pcre/php_pcre.c.orig	Fri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c	Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
 	REGISTER_LONG_CONSTANT("PREG_SPLIT_DELIM_CAPTURE", PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
 	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;
 }
 /* }}} */
@@ -130,6 +121,16 @@
 }
 /* }}} */
 
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+	pcre_malloc = php_pcre_malloc;
+	pcre_free = php_pcre_free;
+
+	return SUCCESS;
+}
+/* }}} */
+
 /* {{{ pcre_get_compiled_regex
  */
 PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) {
@@ -1527,7 +1528,7 @@
 	pcre_functions,
 	PHP_MINIT(pcre),
 	PHP_MSHUTDOWN(pcre),
-	NULL,
+	PHP_RINIT(pcre),
 	NULL,
 	PHP_MINFO(pcre),
 	NO_VERSION_YET,

Here is the patch to fix it on php-4.3.6:

--- ext/pcre/php_pcre.c.orig	Fri Apr 16 09:21:14 2004
+++ ext/pcre/php_pcre.c	Fri Apr 16 09:23:36 2004
@@ -106,15 +106,6 @@
 	REGISTER_LONG_CONSTANT("PREG_SPLIT_DELIM_CAPTURE", PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT);
 	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;
 }
 /* }}} */
@@ -130,6 +121,16 @@
 }
 /* }}} */
 
+/* {{{ PHP_RINIT_FUNCTION(pcre) */
+static PHP_RINIT_FUNCTION(pcre)
+{
+	pcre_malloc = php_pcre_malloc;
+	pcre_free = php_pcre_free;
+
+	return SUCCESS;
+}
+/* }}} */
+
 /* {{{ pcre_get_compiled_regex
  */
 PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) {
@@ -1527,7 +1528,7 @@
 	pcre_functions,
 	PHP_MINIT(pcre),
 	PHP_MSHUTDOWN(pcre),
-	NULL,
+	PHP_RINIT(pcre),
 	NULL,
 	PHP_MINFO(pcre),
 	NO_VERSION_YET,

Same problem here with the lasted stable release PHP 4.3.6

OS    : VineLinux2.6r4(kernel2.4.22)
Apache: 2.0.49
PHP   : 4.3.6

FreeBSD port works fine on Linux too.
Without patch, 4.3.6 also caused Apache's segfault error. So Apache crashed everytime log files were rotated by cron.
Thank you so much.

I continue to have problems with this, on FreeBSD 5.2.1 
using ale's patched port for 4.3.6 and apache 2.0.49.

apache seems to survive a graceful restart when I start 
it without SSL, but if I stop apache it leaves behind a 
bunch of httpd processes that I have to kill.

If I start apache with SSL then it does not survive the 
graceful restart.

Can you try this alternative patch:

http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch

I tried jorton's "alternative patch" with PHP 4.3.6 and Apache 2.0.49 (with SSL) on an otherwise standard RedHat 9 on Intel. I can confirm it works (that is, I can restart Apache) on 2 different systems. YEAH!!!!!!

Previous to patching, it did not work (that is, Apache errored out with these messages in the Apache error log:

[Wed Mar 31 17:14:43 2004] [notice] SIGHUP received.  Attempting to restart
[Wed Mar 31 17:14:43 2004] [notice] seg fault or similar nasty error detected in the parent process
[Wed Mar 31 17:14:48 2004] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run?

OS    : VineLinux2.6r4(kernel2.4.22)
Apache: 2.0.49
PHP   : 4.3.6

I tried jorton's "alternative patch" too.
With or without SSL Apache behave properly when it catch 'HUP' or 'USR1' signal.

I continue to have a problem on graceful restart when 
using the alternative patch. No error is logged but 
Apache stops responding after `apachectl graceful' or 
sending HUP. It does seem to work with a normal stop/
startssl. I'm on FreeBSD 5.2.1, whereas the others, 
for whom it's working, are on Linux.

I've reverted to a backup of 4.3.4 and am looking into 
FastCGI as an alternative.

php dot 5 dot bluemonster at xoxy dot net, can you get a core dump and backtrace?  If it's only triggered by use of mod_ssl, it sounds like a different bug.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

I have verified that this bug is really fixed this time in PHP 4.3.7.

From inspecting the source, it appears fixed in PHP 5.0RC2 (but I haven't verified by it).

I tried on 4.3.7_1 from ports Freebsd-5.2.1-RELEASE-p8 and apache 2.0.49 and problem is still here. When i remove php from httpd.conf restart, graceful and stop is ok. Else i got dump.