|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2010-09-20 07:28 UTC] j dot henge-ernst at interexa dot de
Description:
------------
An Exception thrown is not caught by the corresponding catch block, instead the global exception handler is invoked. That only happens on one page during a long selenium test case. The bug is reproduceable with the selenium test script, but stripping the code to a small example does not result in an error. Will will add the stripped version of the code which does not fail, but show the code.
The System is a 64bit Zend Server 5.3 CE on CentOS 5.5. The same code on a Zend Server 5.2 CE does not have this problem. The problem also occurred in PHP 5.3.2
In the example script $defer should be set to true but instead of catching the excepetion in that block the global exception handler is called.
A fix for this is currently to use bofre the throw:
if (version_compare(PHP_VERSION, '5.3.0', '>=') && version_compare(PHP_VERSION, '5.3.3', '<=')) {
set_exception_handler(create_function('$exception', 'return $exception instanceof iwat_ui_controller_ObjectSaveDeferredException ? true : userExceptionHandler($exception);'));
}
as the application behaves as expected, but that bug still exists. Disabling all Zend modules has no effect
Test script:
---------------
try {
doSave();
} catch (iwat_ui_controller_ObjectSaveDeferredException $e) {
$defer = true;
} catch (IWATException $e) {
}
function doSave() {
throw new iwat_ui_controller_ObjectSaveDeferredException();
}
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2020 The PHP GroupAll rights reserved. |
Last updated: Fri Sep 18 17:01:53 2020 UTC |
We have tracked down the problem further using the Zend Code Tracer. It shows that before the throw is executed several objects are freed and there __destruct are called. After that the Execution stack seems to be corrupt and the Exception is not caught on the expected place. Improving the testscript and adopting these experience still don't yield that problem. It seems that it only happens if the garbage collection? is run at the same time. For one executing path the exception works, but for another execution path it yields that error because additional objects are created. In the __destruct we free additional references to other object so we do not have a memory problem in PHP 5.2.x The __destruct now looks like and fixes the problem: public function __destruct(){ if (version_compare(PHP_VERSION, '5.3.0', '>=')) { return; } $this->_invalidateFieldChanges(); $this->_objects = null; $this->_data = null; $this->_getfcache = null; } Url to the code traces: http://entw.mainz.interexa.de/entw/hernst/phpbuild/phpbug52890-zend-code-trace-zsf.zip (15MB) File trace-0-15823-1-20100924.zsf has that error, file trace-0-16180-1-20100924.zsf works as expected. File trace-0-29017-1-20100924.zsf also does not catch an exception but is simpler and has less references to other objects. I will also provide the xml files of the trace if the export works in the Zend Server.I'm experiencing the same in PHP 5.3.3 under Windows XP SP3, running as an apache 2.2.9 module. An exception is thrown but is only caught by the outer most catch block. i.e: try { try { throw new Exception('foo'); } catch(Exception $e) { //Execution should follow here } } catch(Exception $e) { //Execution follows here } Although in my case there's no __destruct method implied