php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #17810 Instability with IIS/ISAPI
Submitted: 2002-06-18 04:05 UTC Modified: 2002-10-03 09:12 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:2 (100.0%)
From: fabien dot dehopre at itn dot skynet dot be Assigned:
Status: Closed Package: IIS related
PHP Version: 4.2.1 OS: Windows 2000 Server
Private report: No CVE-ID: None
 [2002-06-18 04:05 UTC] fabien dot dehopre at itn dot skynet dot be
We have installed PHP 4.2.1 on Windows 2000 Server (IIS 5.0) as an ISAPI Filter.

When we make a charge test (+/- 15 requests per second), the php returns a "Fatal Error: Call to undefined function:  dirname()" after +/- 70 seconds of this test.

After the test, the php always returns this error until we restart the server.

Sometime, we have also an ISAPI access violation at address xxxxxxxx (I don't remember what address) and we must restart the server to resolve this error.

Php is installed with ASP and ColdFusion.

There is a response from the server when the error occurs:

----------------------------------------------------------
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 17 Jun 2002 15:59:03 GMT
Content-type: text/html
X-Powered-By: PHP/4.2.1

<br />
<b>Fatal error</b>:  Call to undefined function:  dirname() in <b>D:\Webcontent\skypass_priv\db\adodb.inc.php</b> on line <b>42</b><br />
----------------------------------------------------------

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-18 04:07 UTC] derick@php.net
please provide a short script which allows us to reproduce this problem.

Derick
 [2002-06-18 04:13 UTC] mfischer@php.net
Please also try the CGI version, the ISAPI version is known to be very unstable.
 [2002-06-18 04:18 UTC] fabien dot dehopre at itn dot skynet dot be
I use ADODB for PHP (http://php.weblogs.com/ADODB).

We use a MS SQL database.

there is a script that can reproduce the error (it's not sure).
<?php
require_once("./db/adodb.inc.php");
$db = &ADONewConnection("mssql");
$db->Connect("xxx.xxx.xxx.xxx","user","password","db_name");
$query = "SELECT TOP 10 * FROM table_name";
$rs = $db->Execute($query);
while (!$rs->EOF)
{
	$obj = $rs->fetchNextObject(false);
	print_r($obj);
	print '<hr>';
}
$rs->Close();
$db->Close();
?>
 [2002-06-18 04:53 UTC] fabien dot dehopre at itn dot skynet dot be
Now when we make a charge test with +/- 4 RPS we get sometime "parse error" and other time we don't get this parse error.

We are in ISAPI because the CGI version use a lot of resources.
 [2002-06-18 04:58 UTC] mfischer@php.net
I advised you to use the CGI version because there hasn't been much development on the ISAPI module and I'm not aware anyone is right now or in the near future working on it.

Updated Summary,Category
 [2002-07-27 21:38 UTC] tshazli at linuxmail dot org
mfischer@php.net;
As you know, windows platform servers represent more than 50% of the internet servers. Whether we like it or not, It is a reality. I like PHP and have been working with it for more than 3 years now. I convinced the company I work for and its clients to use PHP instead of J2EE or ASP or Coldfusion and many others. 
PHP cannot work on a live windows erver with CGI. It uses alot of resources and on heavy load, The server maxs up and dies. ISAPI is the "only" realistic way. If you want PHP to compete and have its presence, Wehether you like it or not, It has to work "fine" on windows platform.
That's all what I wanted to say.

For you guys who experience this problem, I found a work around to "reduce" the effect of the problem. Pls go to bug #15333
thanks.
 [2002-07-27 21:49 UTC] rasmus@php.net
Like it or not, but 90% of the people who contribute to PHP do not use Windows, so it is natural that Windows issues do not receive as much attention.  Feel free to contribute Windows-related fixes or go out there and convince some of all these Windows users to help out.  
 [2002-09-06 21:13 UTC] tshazli at linuxmail dot org
Ok, here is the thing:
I have 2 servers load balancing each other. had this problem with one of our servers (PIII dual processor) but not with the other which is a single processor. I tried to format the server, reinstall everything all over again, not apply microsoft patches/fixes...etc. still the problem occurs ONLY on the dual processor server. Then I tried to take one processor out of that box and guess what...IT worked flawlessly. I stress tested it with heavy load test for hours and not once I got the error ever again. I put the processor back to the box and tested it. I got the error again. I tried that many times. Always get the error with dual processor but not even once with single processor.

So how to work around the problem? use single processor server. 
What causes the problem? dont know..It is between PHP and IIS. I am trying to find out the problem by debuging the services but if anyone is interested in reproducing the problem and trying to debug it, use dual processor with win2000 server and IIS5 with any php ver >=4.2.1 and use ADODB or MSSQL connections. Stress test it and you will get the error.
 [2002-09-07 00:07 UTC] kalowsky@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Okay like I said in the other bug, please try a new snapshot, because there was a bugfix that took care of some of these issues on Windows (mainly dealing with dual procs, but it effects all).  
 [2002-09-26 20:08 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2002-10-03 09:12 UTC] fabien dot dehopre at itn dot skynet dot be
no more help needed for the moment
Thanks
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Sat Dec 06 00:00:02 2025 UTC