php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27209 Fails to Create COM Object at 2400 Pages Served
Submitted: 2004-02-10 11:07 UTC Modified: 2004-03-23 18:19 UTC
Votes:6
Avg. Score:3.7 ± 0.7
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: timjensen at rtsports dot com Assigned: wez (profile)
Status: No Feedback Package: COM related
PHP Version: 5CVS-2004-02-11 OS: Win2k
Private report: No CVE-ID: None
 [2004-02-10 11:07 UTC] timjensen at rtsports dot com
Description:
------------
OS: Windows 2000 Server SP4
Server Version: Apache/1.3.27 (Win32) mod_gzip/1.3.26.1a PHP/4.3.5RC2

Using a Visual Basic created COM object with PHP 4.3.5RC2, I always get the following error after 2400 or so pages served:

Warning: (null)(): Unable to obtain IDispatch interface for CLSID {0FE9E8B0-1AA7-4929-83FA-A5441A445D90}: CoInitialize has not been called. in f:\rtff\php\test.php on line 9

Here is the simple test code I use to replicate the problem:

  $vb = new COM("gatewaysoftware.Tax");
  echo "<h3>" . $vb->Compute($STATE) . "</h3>\n";
  $vb->Release();
  $vb = null;

With PHP 4.2.1 this problem does not occur and millions of pages can be served with the exact same PHP code, COM
object, and php.ini without the problem appearing.

ab (Apache Bench) can be used to replicate the problem in seconds.   





Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-10 14:23 UTC] timjensen at rtsports dot com
5.0.0 beta 3 is a little better.  I can consistently get
4400 pages served before it can no longer create a COM
object.  The error is different with 5.0:

Failed to create COM object `gatewaysoftware.Tax': Not enough storage is available to complete this operation. ' in f:\RTFF\php\test.php:9 Stack trace: #0 {main} thrown in f:\RTFF\php\test.php on line 9

Windows shows 234k of total commit charge of the available 1.5Gb RAM used at this point.   

Also note, it looks like Apache 1.3.27 with PHP5 bleeds 4k to 8k of  memory for every page served with the COM object creation.  Previous version of PHP bled too, but not nearly as much. 

I tested several version of PHP with apache bench, here are the results:

4.2.1         1,000,000 pages OK
4.2.3         1,000,000 pages OK
4.3.0         Approx 2200 pages, then fails on COM create
4.3.4         Approx 2200 pages, then fails on COM create
4.3.5rc3      Approx 2200 pages, then fails on COM create
5.0.0b3       Approx 4400 pages, then fails on COM create
 [2004-02-10 15:32 UTC] wez@php.net
Please try a php 5 snapshot (not beta 3) as a problem
related to COM cleanup has been fixed since beta 3.
 [2004-02-10 17:21 UTC] timjensen at rtsports dot com
Ok, I have tried it with the PHP5-200402102030 snapshot.
it fails immediately on the first page served with the following error:

Fatal error: Uncaught exception 'com_exception' with message 'Parameter 0: Type mismatch. ' in f:\RTFF\php\test.php:18 Stack trace: #0 {main} thrown in f:\RTFF\php\test.php on line 18

If I change the test PHP code to use a bad variable as input to the COM object's method where it fails, I get a parameter 1 error.  So guessing Parameter 0 was the return value,
I did some hunting around on the web and found some quotes about the parameter list being 0-based, but the parameter type list being 1-based.  Then one-off errors often result parameter 0 always being considered an INT.  So I added a test method to my COM object that returns a Visual Basic LONG and re-ran my test code.  It can now run 10k plus pages with no errors.

Is it required my COM objects must have a return value of
INT ?

The only problem is I get an "Error Member not found" on the 
$comobject->Release();  method.
 [2004-03-15 10:58 UTC] wez@php.net
Please post the definition of the method that fails (the IDL is preferable), along with a var_dump($STATE).

$vb->Release() does not exist in PHP 5, since it doesn't
make sense; use $vb = null; instead.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 01 17:01:32 2024 UTC