Bug #15275 Updated: Apache 1.3.20 won't start with newly compiled PHP 4.1.1
| From: | sniper@php.net | 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