|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Feb 22 17:01:28 2025 UTC |
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.