| Bug #27810 | Apache-2.0.49 crashes on graceful/restart | ||||
|---|---|---|---|---|---|
| Submitted: | 31 Mar 2004 1:55pm UTC | Modified: | 23 Apr 2004 7:59pm UTC | ||
| From: | renato at galle dot com dot br | Assigned to: | |||
| Status: | Closed | Category: | Apache2 related | ||
| Version: | 4.3.5 | OS: | FreeBSD-5.2.1-RELEASE-p4 | ||
| Votes: | 10 | Avg. Score: | 4.6 ± 0.8 | Reproduced: | 8 of 8 (100.0%) |
| Same Version: | 3 (37.5%) | Same OS: | 1 (12.5%) | ||
[31 Mar 2004 1:55pm UTC] renato at galle dot com dot br
[31 Mar 2004 2:04pm 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.
[31 Mar 2004 3:55pm 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...
[1 Apr 2004 4:50am 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...
[1 Apr 2004 5:39am 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
[1 Apr 2004 5:39am 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
[1 Apr 2004 10:36am 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
[1 Apr 2004 1:20pm 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
[1 Apr 2004 10:16pm 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?
[2 Apr 2004 12:04pm 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).
[3 Apr 2004 9:26pm 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.
[4 Apr 2004 5:33am 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.
[5 Apr 2004 3:43pm UTC] thomas at vermoe dot dk
It defently doesnt work on: FreeBSD 4.8, apache 2.0.49, php4-4.3.5 /thomas
[9 Apr 2004 1:16am 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.
[9 Apr 2004 11:19am UTC] rasmus@php.net
Try the latest snapshot. It should be fixed.
[10 Apr 2004 4:44am 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"
[10 Apr 2004 9:21pm 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??
[11 Apr 2004 12:12pm 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...
[11 Apr 2004 1:45pm 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...
[12 Apr 2004 2:55am 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.
[13 Apr 2004 7:28pm 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.
[15 Apr 2004 4:10pm 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.
[15 Apr 2004 5:45pm 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
[16 Apr 2004 3:35am 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.
[16 Apr 2004 7:46am UTC] ale at FreeBSD dot org
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
[16 Apr 2004 11:28am UTC] noackjr at alumni dot rice dot edu
Bless you -- the FreeBSD port works flawlessly for me now.
[19 Apr 2004 6:40pm 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.
[19 Apr 2004 7:09pm 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,
[19 Apr 2004 7:09pm 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,
[20 Apr 2004 4:49pm UTC] paul at vanbrouwershaven dot com
Same problem here with the lasted stable release PHP 4.3.6
[21 Apr 2004 7:46am 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.
[21 Apr 2004 3:58pm 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.
[22 Apr 2004 12:26am UTC] jorton at redhat dot com
Can you try this alternative patch: http://www.apache.org/~jorton/php-4.3.6-pcrealloc.patch
[22 Apr 2004 1:22am 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?
[22 Apr 2004 4:33pm 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.
[22 Apr 2004 10:40pm 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.
[23 Apr 2004 1:16pm 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.
[23 Apr 2004 7:59pm 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.
[3 Jun 2004 7:16pm 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).
[22 Jun 2004 1:24pm 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.
