Edit report at https://bugs.php.net/bug.php?id=60978&edit=1
ID: 60978
Comment by: laruence@php.net
Reported by: thekid@php.net
Summary: exit code incorrect
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Windows
PHP Version: 5.4.0RC7
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
I think a appropriate way to fix these issues(memleak, xdebug, this issue) is
catch->efree->throw. I have made a patch.
Derick, what do you think?
Previous Comments:
------------------------------------------------------------------------
[2012-02-06 09:55:47] laruence@php.net
The following patch has been added/updated:
Patch Name: wrong_exit_code.patch
Revision: 1328522147
URL: https://bugs.php.net/patch-display.php?bug=60978&patch=wrong_exit_code.patch&revision=1328522147
------------------------------------------------------------------------
[2012-02-05 13:36:33] thekid@php.net
Checking SVN history revealed r322922 as the cause - see http://svn.php.net/viewvc?view=revision&revision=322922.
Reverting it fixes this bug.
The commit mentions a relation to bug #60218 but I'm not sure why it "Reinstated correct
return values". Before this fix the code in zend_execute_API.c read:
zend_execute(new_op_array TSRMLS_CC);
[...]
retval = SUCCESS;
After the fix it read:
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try();
[...]
retval = SUCCESS;
Finally, r322922 changed it to:
retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_catch {
retval = FAILURE;
} zend_end_try();
The zend_catch "block" is executed whenever SETJMP returns non-zero, so basically when
LONGJMP is called, which is the case for zend_bailout(), which again is used by exit() and die(). To
my eyes, this *changed* the return value instead of reinstating it.
@derick, maybe you can shed some light on this commit?
------------------------------------------------------------------------
[2012-02-05 10:54:30] thekid@php.net
Test suite:
<?php
if (!isset($argv[1])) {
exit("*** Usage: php exit.php /path/to/php/binary\n");
}
$php= realpath($argv[1]);
if (!is_executable($php)) {
exit("*** PHP Binary '$argv[1]' is not executable\n");
}
$tests= array(
"echo '';" => 0,
"exit('test');" => 0,
"exit(2);" => 2,
"fatal();" => 255,
"\$->" => 254,
"throw new Exception('test');" => 255
);
foreach ($tests as $source => $expected) {
$cmd= '"'.$php.'" -r "'.$source.'"
2>&1';
$output= array();
exec($cmd, $output, $actual);
if ($actual === $expected) {
printf("%-30s: [OK]\n", $source);
} else {
printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected, $actual,
implode(' ', $output));
}
}
?>
------------------------------------------------------------------------
[2012-02-05 10:01:41] thekid@php.net
...oh, and:
* Uncaught exception exit, php -r 'throw new Exception("test");' ; echo
$? = 255
------------------------------------------------------------------------
[2012-02-05 09:59:54] thekid@php.net
Your patch breaks the exitcode 254 for parse errors.
We have the following cases and expected exit codes:
* Clean exit, php -r 'echo "";' ; echo $? = 0
* Clean explicit exit with message, php -r 'exit("test");' ; echo
$? = 0
* Clean explicit exit with exitcode, php -r 'exit(2);' ; echo $? = 2
* Exit after a fatal error, php -r '$fatal->error();' ; echo $? = 255
* Exit after compile error, php -r '$->' ; echo $? = 254
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=60978
--
Edit this bug report at https://bugs.php.net/bug.php?id=60978&edit=1