ID: 27810 Comment by: towerofpower at operamail dot com Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2004-04-15 17:45:01] 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-15 16:10:22] 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-13 19:28:27] 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-12 02:55:30] 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-11 13:45:25] 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... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27810 -- Edit this bug report at http://bugs.php.net/?id=27810&edit=1
