0001089: Call to php_sapi_name() breaks exception handling - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0001089	Xdebug	Uncategorized	public	2014-11-20 14:13	2015-01-07 10:26

Reporter	edrjoe	Assigned To
Priority	high	Severity	major	Reproducibility	always
Status	resolved	Resolution	no change required
Platform	Linux	OS	RHEL	OS Version	6.4
Product Version	2.2.5

Summary	0001089: Call to php_sapi_name() breaks exception handling
Description	Combination of XDebug 2.2.5-6 + OpCache-7.0.4 + PHP 5.6.3 (turn either Xdebug OR ZO+ off, and problem goes away...), and a call to php_sapi_name() causes Exceptions that are caught and rethrown to immediately propagate to exception handler and ignore further catch statements.
Steps To Reproduce	<?php if(php_sapi_name()) { try { // 1 try { // 2 throw new Exception('Raaaa'); } catch (Exception $e) { // 2 echo 'hello'; throw $e; } } catch (Exception $e1) { // 1 // squash } }
Additional Information	Disabling either XDebug OR ZO+ fixes the issue. The call to php_sapi_name() is required. php_sapi_name() call has to be in logic - just calling it on it's own doesn't work. Workaround: use PHP_SAPI constant instead.
Tags	No tags attached.

Operating System
PHP Version	5.6.0-5.6.4

edrjoe 2014-11-20 14:26 reporter ~0002914	Actually, this appears to happen with a host of different native function calls: php_uname() php_ini_loaded_file() both cause the same error.

derick 2015-01-05 23:03 administrator ~0002957 Last edited: 2015-01-05 23:06	I can reproduce this, and have pushed a test file (tests/bug01089.phpt) to https://github.com/derickr/xdebug/tree/issue1089-error-handler From what I can see, there are different oparrays being generated for opcache.enable_cli=1 vs opcache.enable_cli=0 (with no other settings changes). I've added the different opcode dumps coming out of VLD for these both cases, as well as with xdebug off for each too. I can't figure out why this goes wrong though, as no valgrind warnings shows up (not even with USE_ZEND_ALLOC=0).

derick 2015-01-07 10:26 administrator ~0002963	This turns out not to be a bug in Xdebug, but in opcache. I can reproduce this on the command line by putting your code in a file (1089.php) and running on the command line: php -e -n -dzend_extension=opcache.so -dopcache.enable_cli=1 1089.php -n disables all INI settings (including loading opcache and xdebug) -e enables "extended information" for use with profilers With the latter turned on, apparently, when Xinchem from Zend looked at it, he found: the problem is: <?php try { // ZEND_EXT_STMT try { // ZEND_EXT_STMT throw.. in zend_update_ext_info which is called in pass_two, the first EXT_STMT will became a NOP opline thus, op_array->try_catch_array[0]->try_op is point to a NOP block, which will be removed in cfg optimization. I'm closing this issue, and a fix for opcache is on the way too.