php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #35872 CLI errors upon exit if class is left on IE
Submitted: 2006-01-02 15:32 UTC Modified: 2007-03-05 15:54 UTC
From: csaba at alum dot mit dot edu Assigned: wharmby (profile)
Status: Closed Package: COM related
PHP Version: 5.1.1 OS: Win XP Pro
Private report: No CVE-ID: None
 [2006-01-02 15:32 UTC] csaba at alum dot mit dot edu
Description:
------------
If IE is left open when a PHP script ends, and we have affixed a class instance to IE, CLI generates an error.

Csaba Gabor from Vienna

Reproduce code:
---------------
<?php
$ie = new COM("InternetExplorer.Application");  // new IE
$ie->visible = true;				// show it
$ie->Navigate2("about:blank");        // give IE empty DOM
while ($ie->readyState<4) usleep(10000);  // wait for ready
class frob { }				  // dummy class
$frob = new frob;			  // instantiate it

$window=$ie->document->parentWindow;      // window ref
$window->execScript("window.myclass=false"); // always allocate ie vars
$window->myclass = $frob;		// pathway to PHP

$window->alert ("Program is ending");	// proof of no errors to here
//$window->myclass = null;    	// CLI errors if this commented out
?>


Expected result:
----------------
PHP is quite good about cleaning up after itself.  I expect PHP to nicely finish and leave IE up, without and CLI error dialogs asking if I want to send a report to Microsoft.

Actual result:
--------------
After dismissing the "Program is ending" alert box, I get the dreaded CLI error dialog asking if I want to send a report to Microsoft.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-01-27 15:27 UTC] wharmby at uk dot ibm dot com
I will take a look at this one next
 [2007-01-31 13:19 UTC] wharmby at uk dot ibm dot com
Commenting out the line 
   
    $window->myclass = null;

in the supplied testcase means that the associated
"com_dotnet_dispatch_wrapper" resource is not destroyed 
until we destroy any remaining resources in the regular 
resource list during request shutdown when zend_deactivate()
calls zend_destroy_rsrc_list(). Unfortunately the dtor for 
this COM resource references the object store which has 
itself already been destroyed earlier in request shutdown
by zend_objects_store_destroy(). Changing the order of
object and resource shutdown might appear to be the easy 
fix but I am sure this will lead to the reverse problem of 
objects referring to resources  when resource has already 
been destroyed. As the references to the object store are 
only required in order to add detail into some COM trace 
entries then simply avoiding the reference when in request shutdown may be the best/simplest approach in this case. 

I will post a fix to Internals once I have something I am happy with.
 [2007-03-02 14:24 UTC] wharmby@php.net
Patch sent to internals list for review.
 [2007-03-05 14:16 UTC] wharmby@php.net
Fix dropped into HEAD. Email sent to Ilia to get OK to drop into 5.2
 [2007-03-05 15:54 UTC] wharmby@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fix now in 5.2.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 08:01:29 2024 UTC