ID: 35872 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Assigned +Status: Closed Bug Type: COM related Operating System: Win XP Pro PHP Version: 5.1.1 Assigned To: wharmby New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2007-03-05 14:16:53] [EMAIL PROTECTED] Fix dropped into HEAD. Email sent to Ilia to get OK to drop into 5.2 ------------------------------------------------------------------------ [2007-03-02 14:24:50] [EMAIL PROTECTED] Patch sent to internals list for review. ------------------------------------------------------------------------ [2007-01-31 13:19:36] 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-01-27 15:27:24] wharmby at uk dot ibm dot com I will take a look at this one next ------------------------------------------------------------------------ [2006-01-02 15:32:12] 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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=35872&edit=1
