Bug #15275 Updated: Apache 1.3.20 won't start with newly compiled PHP 4.1.1

From: Date: Thu, 13 Jun 2002 22:05:52 +0000
Subject: Bug #15275 Updated: Apache 1.3.20 won't start with newly compiled PHP 4.1.1
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-10404@lists.php.net to get a copy of this message
ID: 15275 Updated by: sniper@php.net Reported By: ms@gps-ulm.de -Status: Open +Status: Bogus Bug Type: Apache related Operating System: SuSE Linux 7.1 Kernel 2.4.2 PHP Version: 4.1.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: ------------------------------------------------------------------------ [2002-02-12 21:16:37] populaer@gmx.de Well, i think it can't be *the* resolution to upgrade the glibc (a very dangerous process ;) ). I have the same problems mit PHP 4.1.1 and Apache 1.3.23. I get no error messages, but the Apache-Webserver doesn't start. Without the entry (LoadModule ...libphp4.so) Apache works fine. Another Question: Does the glibc of anybody includes the patches for the heap overflow in glibc globbing functions ?! Since I installed this Patch, a running Apache-PHP4.06 installation won't run anymore... Kernel: 2.2.19 glibc: 2.1.3 Regards, Michael ------------------------------------------------------------------------ [2002-02-01 04:59:46] jojo-in-london@automatix.de Worked out on the problem. The suggestion to step back to 4.0.6 does also not work. But I found the root of the problem. Those error-systems were glibc 2.1.x based. After upgrading to glibc 2.2.5 / and all other aditional tools (gcc to 2.95.3, binutils, automake, autoconf, gettext) everz this is reallz working fine again. Simply works. Perhaps drop a notice for other users ? mfG J. Sauer ------------------------------------------------------------------------ [2002-01-31 10:14:27] jojo-in-london@automatix.de This is the config: ./configure \ --prefix=/usr \ --sbindir=/usr/sbin \ --bindir=/usr/bin \ --libexecdir=/usr/lib/apache/modules \ --datadir=/home/fileserver/documents \ --sysconfdir=/etc/httpd \ --with-config-file-path=/etc/httpd/php.ini \ --localstatedir=/var \ --with-apxs=/usr/sbin/apxs \ --enable-ftp \ --with-ftp \ --enable-versioning \ --enable-tracking-vars \ --enable-url-includes \ --enable-sysvshm \ --enable-sysvsem \ --with-sapdb=/usr/sapdb/depend \ --with-gdbm \ --enable-trans-sid \ --enable-magic-quotes \ --enable-libgcc \ --enable-calendar \ --disable-mysql \ --with-mysql=no \ --with-gnu-ld \ --enable-ftp \ --with-ndbm \ --with-dbase \ --with-gettext \ --with-gd \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-zlib-dir=/usr \ --enable-memory-limit Core Dump occour on start up. Last words off strace -f httpd ----------------------------------------------------- mprotect(0x4071a000, 56752, PROT_NONE) = 0 old_mmap(0x4071a000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x33000) = 0x4071a000 old_mmap(0x40726000, 7600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40726000 close(4) = 0 mprotect(0x40617000, 217088, PROT_READ|PROT_WRITE) = 0 mprotect(0x40617000, 217088, PROT_READ|PROT_EXEC) = 0 mprotect(0x4045c000, 1400832, PROT_READ|PROT_WRITE) = 0 mprotect(0x4045c000, 1400832, PROT_READ|PROT_EXEC) = 0 mprotect(0x40377000, 630784, PROT_READ|PROT_WRITE) = 0 mprotect(0x40377000, 630784, PROT_READ|PROT_EXEC) = 0 mprotect(0x401e5000, 1212416, PROT_READ|PROT_WRITE) = 0 mprotect(0x401e5000, 1212416, PROT_READ|PROT_EXEC) = 0 getpid() = 22607 getrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="KBDev1.uk-london", ...}) = 0 rt_sigaction(SIGRT_0, {0x40690f94, [], 0x4000000}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x40690684, [], 0x4000000}, NULL, 8) = 0 rt_sigaction(SIGRT_2, {0x4069101c, [], 0x4000000}, NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0 munmap(0x4034d000, 13070) = 0 --- SIGSEGV (Segmentation fault) --- My rating: PHP 4.1.1 + Apache 1.3.22 + Linux 2.2.16 (Redhat 6.2/Cobalt Cube 3) + SapDB 7.3.00.18 is currently not usable. Workaround: Step Back to 4.0.6 mfG Juergen Sauer jojo@automatix.de jojo-in-london@automatix.de ------------------------------------------------------------------------ [2002-01-30 11:37:15] jojo@automatix.de PHP 4.1.1 & Apache 1.3.22 on Cobald Cube 3/Linux 2.2.16, has the same bug. Jojo ------------------------------------------------------------------------ [2002-01-29 08:46:18] ms@gps-ulm.de Line 224 of http.conf is : LoadModule php4_module libexec/libphp4.so ------------------------------------------------------------------------ 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/15275 -- Edit this bug report at http://bugs.php.net/?id=15275&edit=1

« previous php.bugs (#10404) next »