Russ Goodwin wrote: > I actually switched to the stock php.ini-recommended to find out if there > was a problem in my php.ini and it behaves no differently. > > All the "extensions=" lines are commented out in that file. > > Thanks for the try. Anything else? I'll take all the advice, hints, and > guesses I can get, as I'm clean out! > > -Russ
Can you display phpinfo()? -- Yasuo Ohgaki > > > > "Yasuo Ohgaki" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >>I guess you are loading incompatible modules from >>your php.ini. >> >>Get rid of all extensions including zend extensions. >> >>-- >>Yasuo Ohgaki >> >>Russ Goodwin wrote: >> >>>Hi- >>> >>>I've searched high and low (bugs.php.net and google) and can't seem to >>> > find > >>>anyone with this same problem, I'm not entirely convinced it's a bug, >>> > but if > >>>I should post it to the bugs db, please let me know... >>> >>>I'm running Apache 1.3.22, MySQL 3.23.46, cURL 7.8, mod_ssl 2.8.5 and >>> > PHP > >>>4.0.6/4.1.1 on RH Linux 6.2 kernel 2.2.18pre11-va2.0smp. (with php as a >>>DSO, mod_ssl static). >>> >>>Using the 4.0.6 module, I have no problems. When I install 4.1.1, then >>> > run > >>>'apachectl startssl', apachectl functions normally, asks for my key's >>>passphrase, then exits. Ordinarily the forked child would stay alive >>> > and > >>>spawn off StartServers children, but instead a 'ps aux' shows no httpd's >>>running. >>> >>>I have about a dozen virtualhosts set up, and when I rip out all but the >>>first 6 and then comment out the ErrorLog and CustomLog lines in the 6th >>>virtualhost setup (or rip the 6th virtualhost altogether), apache starts >>>fine. I've tried re-ordering the virtualhosts but that doesn't help. I >>>found in the apache docs that it might be a file descriptor limit >>> > problem, > >>>and posted to the php.install group asking if anyone had seen this, but >>> > got > >>>no response. I'm convinced it's not a file descriptor problem, though >>>because running 'limit' shows "descriptors 1024" and "openfiles >>>1024" (everything else unlimited). The segfault only happens with the >>> > newer > >>>php though, so I'm posting here... if you think it's an apache (or >>> > something > >>>else) problem, please let me know. >>> >>>I've uncommented the 6th virtualhost's log directives and run 'httpd -X' >>> > to > >>>get a core file, and the backtrace says: >>> >>>#gdb /usr/local/apache/bin/httpd /tmp/core >>>GNU gdb 19991004 >>>Copyright 1998 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-redhat-linux"... >>>Core was generated by `httpd -X'. >>>Program terminated with signal 11, Segmentation fault. >>>Reading symbols from /lib/libm.so.6...done. >>>Reading symbols from /lib/libcrypt.so.1...done. >>>Reading symbols from /lib/libdb.so.3...done. >>>Reading symbols from /usr/local/lib/libexpat.so.0...done. >>>Reading symbols from /lib/libdl.so.2...done. >>>Reading symbols from /lib/libc.so.6...done. >>>Reading symbols from /lib/ld-linux.so.2...done. >>>Reading symbols from /lib/libnss_files.so.2...done. >>>Reading symbols from /usr/local/apache/libexec/libphp4.so...done. >>>Reading symbols from /lib/libresolv.so.2...done. >>>Reading symbols from /lib/libpam.so.0...done. >>>Reading symbols from /home/mysql/lib/mysql/libmysqlclient.so.10...done. >>>Reading symbols from /usr/local/lib/libcurl.so.2...done. >>>Reading symbols from /lib/libnsl.so.1...done. >>>Reading symbols from /usr/lib/libz.so.1...done. >>>#0 strcmp (p1=0x403785c0 <Address 0x403785c0 out of bounds>, >>> > p2=0x406935c0 > >>>"DESX") at ../sysdeps/generic/strcmp.c:38 >>>38 ../sysdeps/generic/strcmp.c: No such file or directory. >>>(gdb) bt >>>#0 strcmp (p1=0x403785c0 <Address 0x403785c0 out of bounds>, >>> > p2=0x406935c0 > >>>"DESX") at ../sysdeps/generic/strcmp.c:38 >>>#1 0x80f984d in obj_name_cmp () >>>Cannot access memory at address 0x3008add8 >>>(gdb) quit >>> >>> >>>If I do an 'strace httpd -X', the last several lines look like this: >>>old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > >>>= 0x401ba000 >>>_llseek(21, 0, [0], SEEK_CUR) = 0 >>>getpid() = 12231 >>>stat("/usr/local/apache/logs/httpd.pid", {st_mode=S_IFREG|0644, >>> > st_size=6, > >>>...}) = 0 >>>time(NULL) = 1011128952 >>>write(2, "[Tue Jan 15 16:09:12 2002] [warn"..., 131) = 131 >>>write(2, "\n", 1) = 1 >>>umask(022) = 02 >>>umask(022) = 022 >>>open("/usr/local/apache/logs/httpd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) >>> > = 3 > >>>umask(02) = 022 >>>fstat64(0x3, 0xbffff1a0) = 0 >>>old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, >>> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > >>>= 0x401bb000 >>>write(3, "12231\n", 6) = 6 >>>close(3) = 0 >>>munmap(0x401bb000, 4096) = 0 >>>open("./php.ini", O_RDONLY) = -1 ENOENT (No such file or >>>directory) >>>open("/usr/local/lib/php.ini", O_RDONLY) = 3 >>>getcwd("/tmp", 4095) = 5 >>>lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 >>>lstat("/usr/local", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = >>> > 0 > >>>lstat("/usr/local/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 >>>lstat("/usr/local/lib/php.ini", {st_mode=S_IFREG|0644, st_size=24208, >>> > ...}) > >>>= 0 >>>ioctl(3, TCGETS, 0xbffff7fc) = -1 ENOTTY (Inappropriate ioctl >>> > for > >>>device) >>>read(3, "[PHP]\n; $Id: php.ini-dist,v 1.78"..., 8192) = 8192 >>>read(3, "n to end users, such as file pat"..., 8192) = 8192 >>>read(3, "CP_PORT or the mysql-tcp entry i"..., 8192) = 7824 >>>read(3, "", 368) = 0 >>>read(3, "", 8192) = 0 >>>ioctl(3, TCGETS, 0xbfffec14) = -1 ENOTTY (Inappropriate ioctl >>> > for > >>>device) >>>close(3) = 0 >>>--- SIGSEGV (Segmentation fault) --- >>>+++ killed by SIGSEGV +++ >>> >>> >>>Interestingly, if I 'strace httpd -X' while using the 4.0.6 module and >>>compare, the last "read(3, "",8192)" call doesn't occur... the close is >>>followed by lots of brk's (dunno if this is of any significance). >>> > Looks to > >>>me like "whatever happens right after reading in php.ini" is causing the >>>segfault. But I don't know what that is or how to fix it. >>> >>>The last line in my ssl_engine_log after a segfault shows: >>>[info] Init: Configuring temporary DH parameters (512/1024 bits) >>> >>>When using 4.0.6, the line after that one is: >>>[info] Init: 2nd startup round (already detached) >>><followed by lots more and a properly functioning httpd> >>> >>>4.1.1 is configured like this: >>> >>> > ./configure --with-mysql=/home/mysql --with-apxs=/usr/local/apache/bin/apxs > >>> --with-curl=/usr/local/lib/libcurl.so --with-openssl --enable-debug >>> >>>4.0.6 is configured like this: >>> >>> > ./configure --with-mysql=/home/mysql --with-apxs=/usr/local/apache/bin/apxs > >>> --with-curl=/usr/local/lib/libcurl.so --with-openssl >>> >>> >>>I'm really stuck, so any help you can offer would be greatly >>> > appreciated. > >>>Thanks. >>> >>>-Russ >>> >>> >>> > > -- Yasuo Ohgaki -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
