Edit report at http://bugs.php.net/bug.php?id=52890&edit=1
ID: 52890
User updated by: j dot henge-ernst at interexa dot de
Reported by: j dot henge-ernst at interexa dot de
Summary: Exception not caught sometimes
-Status: Open
+Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.3
Block user comment: N
New Comment:
Sorry have to correct me, with snapshot 5.3-201009280630 the problem no
longer occurs. Might be fixed with bug #52361 which hadn't made it into
5.3.3
Previous Comments:
------------------------------------------------------------------------
[2010-09-28 10:10:55] j dot henge-ernst at interexa dot de
Happend with php 5.2.2 from Zend Server, happens with php 5.3.3 from
php.net and from Zend Server 5.0.3 and with snapshot 5.3-201009280630
from php.net
configure was:
'./configure' '--with-libdir=lib64'
'--prefix=/usr/local/php.net/5.3-201009280630' '--with-mysql'
'--enable-zip' '--enable-pcntl' '--with-gd' '--with-apxs2'
'--with-freetype-dir=yes' '--enable-gd-native-ttf' '--enable-mbstring'
'--enable-calendar' '--enable-pcntl'
'--with-oci8=instantclient,/interexa/lib64/oracle/instantclient_11_2'
'--with-config-file-path=/usr/local/zend/etc'
------------------------------------------------------------------------
[2010-09-28 03:49:27] wakamonka747 at hotmail dot com
Forgot to mention that I checked this behaviour with xdebug. You
actually see how it just skips there.
------------------------------------------------------------------------
[2010-09-28 03:47:22] wakamonka747 at hotmail dot com
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
------------------------------------------------------------------------
[2010-09-27 16:09:16] f...@php.net
Please try to reproduce with PHP 5.3.3 from
http://www.php.net/downloads.php
instead of Zend Server or file a bug report with Zend.
------------------------------------------------------------------------
[2010-09-24 13:26:24] j dot henge-ernst at interexa dot de
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52890
--
Edit this bug report at http://bugs.php.net/bug.php?id=52890&edit=1
