php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27810 Apache-2.0.49 crashes on graceful/restart
Submitted: 2004-03-31 13:55 UTC Modified: 2004-04-23 19:59 UTC
Votes:10
Avg. Score:4.6 ± 0.8
Reproduced:8 of 8 (100.0%)
Same Version:3 (37.5%)
Same OS:1 (12.5%)
From: renato at galle dot com dot br Assigned:
Status: Closed Package: Apache2 related
PHP Version: 4.3.5 OS: FreeBSD-5.2.1-RELEASE-p4
Private report: No CVE-ID: None
 [2004-03-31 13:55 UTC] renato at galle dot com dot br
Description:
------------
When compile php-4.3.5 with PCRE support with apache-2.0.49 and try to graceful or restart apache a signal 11 (core dumped) error occours.

I move ext/pcre directory from php-4.3.4 to php-4.3.5 src directory and recompile, and all works fine.

This problem occours on FreeBSD:
http://www.freebsd.org/cgi/query-pr.cgi?pr=64904

on Linux:
http://bugs.php.net/bug.php?id=27735

and on Solaris 9:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28086

To reproduce do this:
- Install apache-2.0.49
- Compile php-4.3.5 with PCRE support using apxs
- run apachectl start
- run apachectl restart or apachectl graceful and apache will die

Actual result:
--------------
root@srv1:/usr/local# gdb /usr/local/sbin/httpd ./httpd.core
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.2
Reading symbols from /usr/lib/libssl.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /lib/libcrypto.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.3
Reading symbols from /usr/local/lib/apache2/libaprutil-0.so.9...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/apache2/libaprutil-0.so.9
Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/libexpat.so.5
Reading symbols from /usr/local/lib/apache2/libapr-0.so.9...(no debugging symbols found)...done.
Loaded symbols for /usr/local/lib/apache2/libapr-0.so.9
Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.2
Reading symbols from /lib/libcrypt.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.2
Reading symbols from /lib/libc.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /usr/local/libexec/apache2/mod_access.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_access.so
Reading symbols from /usr/local/libexec/apache2/mod_auth.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_auth.so
Reading symbols from /usr/local/libexec/apache2/mod_auth_anon.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_auth_anon.so
Reading symbols from /usr/local/libexec/apache2/mod_auth_dbm.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_auth_dbm.so
Reading symbols from /usr/local/libexec/apache2/mod_include.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_include.so
Reading symbols from /usr/local/libexec/apache2/mod_deflate.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_deflate.so
Reading symbols from /usr/local/libexec/apache2/mod_log_config.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_log_config.so
Reading symbols from /usr/local/libexec/apache2/mod_env.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_env.so
Reading symbols from /usr/local/libexec/apache2/mod_mime_magic.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_mime_magic.so
Reading symbols from /usr/local/libexec/apache2/mod_cern_meta.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_cern_meta.so
Reading symbols from /usr/local/libexec/apache2/mod_expires.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_expires.so
Reading symbols from /usr/local/libexec/apache2/mod_headers.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_headers.so
Reading symbols from /usr/local/libexec/apache2/mod_usertrack.so...(no debugging symbols found)...done.
Loaded symbols for /usr/local/libexec/apache2/mod_usertrack.so
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x2848bd90 in ?? ()
(gdb) bt
#0  0x2848bd90 in ?? ()
#1  0x0806e4af in regex_cleanup ()
#2  0x28259bcd in run_cleanups () from /usr/local/lib/apache2/libapr-0.so.9
#3  0x282592fc in apr_pool_clear () from /usr/local/lib/apache2/libapr-0.so.9
#4  0x0806c73d in main ()
#5  0x0805d092 in _start ()
(gdb)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-03-31 14:04 UTC] iliaa@php.net
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.


 [2004-03-31 15:55 UTC] noackjr at alumni dot rice dot edu
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...
 [2004-04-01 04:50 UTC] as at netoholic dot de
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...
 [2004-04-01 05:39 UTC] packager at rabbito dot org
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
 [2004-04-01 05:39 UTC] packager at rabbito dot org
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
 [2004-04-01 10:36 UTC] nti at w4w dot net
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
 [2004-04-01 13:20 UTC] nti at w4w dot net
--- 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
 [2004-04-01 22:16 UTC] noackjr at alumni dot rice dot edu
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?
 [2004-04-02 12:04 UTC] loki at arete dot cc
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).
 [2004-04-03 21:26 UTC] noackjr at alumni dot rice dot edu
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.
 [2004-04-04 05:33 UTC] taka-o at pop07 dot odn dot ne dot jp
--- 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.
 [2004-04-05 15:43 UTC] thomas at vermoe dot dk
It defently doesnt work on:

FreeBSD 4.8, apache 2.0.49, php4-4.3.5

/thomas
 [2004-04-09 01:16 UTC] loki at arete dot cc
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.
 [2004-04-09 11:19 UTC] rasmus@php.net
Try the latest snapshot.  It should be fixed.
 [2004-04-10 04:44 UTC] nti at w4w dot net
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"
 [2004-04-10 21:21 UTC] sdfsdhfkg at hotmail dot com
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??
 [2004-04-11 12:12 UTC] tomdkat at comcast dot net
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...
 [2004-04-11 13:45 UTC] tomdkat at comcast dot net
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...
 [2004-04-12 02:55 UTC] loki at arete dot cc
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.
 [2004-04-13 19:28 UTC] loki at arete dot cc
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.
 [2004-04-15 16:10 UTC] danu at drydog dot com
NOT fixed with php-4.3.6

I just tried this and it isn't fixed with PHP 4.3.6 either.
 [2004-04-15 17:45 UTC] danu at drydog dot com
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
 [2004-04-16 03:35 UTC] towerofpower at operamail dot com
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.
 [2004-04-16 11:28 UTC] noackjr at alumni dot rice dot edu
Bless you -- the FreeBSD port works flawlessly for me now.
 [2004-04-19 18:40 UTC] remco at linux-adept dot nl
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.
 [2004-04-19 19:09 UTC] renato at galle dot com dot br
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,
 [2004-04-19 19:09 UTC] renato at galle dot com dot br
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,
 [2004-04-20 16:49 UTC] paul at vanbrouwershaven dot com
Same problem here with the lasted stable release PHP 4.3.6
 [2004-04-21 07:46 UTC] sugihara at gix dot or dot jp
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.
 [2004-04-21 15:58 UTC] php dot 5 dot bluemonster at xoxy dot net
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.
 [2004-04-22 00:26 UTC] jorton at redhat dot com
Can you try this alternative patch:

http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch
 [2004-04-22 01:22 UTC] danu at drydog dot com
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?
 [2004-04-22 16:33 UTC] sugihara at gix dot or dot jp
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.
 [2004-04-22 22:40 UTC] php dot 5 dot bluemonster at xoxy dot net
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.
 [2004-04-23 13:16 UTC] jorton at redhat dot com
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.
 [2004-04-23 19:59 UTC] iliaa@php.net
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.


 [2004-06-03 19:16 UTC] danv at drydog dot com
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).
 [2004-06-22 13:24 UTC] uros at sir-mag dot com
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Oct 16 05:01:27 2024 UTC