Bug #11921: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
| From: | shinelight at excite dot com | Date: | Fri, 06 Jul 2001 08:38:22 +0000 |
| Subject: | Bug #11921: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-59055@lists.php.net to get a copy of this message | ||
From: shinelight@excite.com
Operating system: Windows 98
PHP version: 4.0.6
PHP Bug Type: Reproducible crash
Bug description: Apache 1.3.20, mod_ssl 2.8.4, PHP 4.0.4 crashes in CGI mode
Using the default PHP 4.0.6 package for Win32 (downloaded straight from php.net), I have found an
interesting combination that causes Apache 1.3.20 to core dump. My objective was to set up an SSL
server to seamlessly work with the Xitami webserver, Apache is the obvious choice here.
The first thing I did was download and install Apache 1.3.20 for Win32. Then, I applied the patches
located in Apache_1.3.20-Mod_SSL_2.8.4-OpenSSL_0.9.6a-WIN32.zip on the contributions page of the
www.modssl.org site. Finally, I configured and set up the SSL virtual server (both a self-signed
and a CA-signed certificate work) and got everything working. I wrote a short Perl script that
would call XiFusion with the correct parameters:
#!c:/perl/bin/perl
$ENV{"SCRIPT_NAME"} = $ENV{"REDIRECT_URL"};
system "c:\\xifusion\\xifusion.exe c:\\php4\\php.exe";
Side Note: I am the author of XiFusion v2.5 (a wrapper for CGIs under the Xitami webserver for
ColdFusion and PHP <http://www.xitami.com/xifusion.zip>).
This setup worked fine...sort of. I have tried everything I can think of to prove that PHP
isn't the culprit, but it is. Here is what happens:
1) The browser connects to the SSL server.
2) The browser request a PHP page. Apache sees that PHP extensions are aliased to a type, thus it
checks out the action it should take. It then executes the previously mentioned Perl script.
3) The Perl script modifies an environment variable and calls XiFusion.
4) XiFusion does its thing and executes PHP (I've checked to see if XiFusion or the Perl
script were the problem and they are not).
5) PHP then starts to process the page.
6) ApacheCore.dll for some reason core dumps. I have no idea why it does this (it is somewhat
random, but *VERY* reproducible).
7) The odd thing is is that when I click "Close" on the dialog box, Apache reloads and
acts like nothing happened...weird (none of the log files show that an error occurred either...even
weirder).
What is even weirder than all that is if I switch from CGI mode to module mode (modify
conf/httpd.conf), there is no problem...even under normal Apache 1.3 API.
I've scoured google.com as well as the PHP databases for any solution to this very interesting
bug. I've been re-building everything (Apache, OpenSSL, mod_ssl) from sources to see if I can
improve the situation any. So far, no luck (no, I didn't forget to replace the DLLs in the
Windows\system directory). I've seen references to the
-DEAPI compile option for PHP, so I will try that out tomorrow to see if that helps (but knowing my
luck so far... :)
This bug is also in PHP v4.0.4.
Pertinent Machine Info.:
OS: Win98
Dual PIII 500 mHz CPUs
384MB RAM (I try to maintain about 150MB free using RamIdle)
18GB HD (5 GB free on the Win98 partition)
I really want to use the XiFusion wrapper program rather than the module since I can get more
control through XiFusion than I can through Apache.
Sorry, no gdb backtrace. My debugging methods are usually lots of good ol' fashioned printf
statements ;)
Thomas Hruska
Shining Light Productions
"Meeting the Needs of Fellow Programmers"
--
Edit Bug report at: http://bugs.php.net/?id=11921&edit=1