[PHP-BUG] Bug #51788 [NEW]: Segfault on get_defined_constants(TRUE)
From: Operating system: Linux PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:Segfault on get_defined_constants(TRUE) Description: get_defined_constants(TRUE) started throwing me segfaults today, for apparently no reason. Worked yesterday, doesn't work today. Test script does only that function and still throws back no data. I can't rule out server configuration, but I have tested for it somewhat, with same results. Apache mod_php5 produces the segfault. PHP CLI does not. bug 15614 Had this problem with print_r(get_defined_constants(TRUE)) in 2002. My segfault is happening with get_defined_constants(TRUE) alone. Ubuntu 10.04 Linux 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 PHP 5.3.2-1ubuntu4 with Suhosin-Patch (built: Apr 9 2010 08:18:14) Zend Engine v2.3.0 with Xdebug v2.0.5 with Suhosin v0.9.29 Apache/2.2.14 (Ubuntu) Test script: --- ?php print_r(get_defined_constants(TRUE)); Expected result: Function works. Actual result: -- [Mon May 10 15:08:44 2010] [notice] child pid 21884 exit signal Segmentation fault (11) -- Edit bug report at http://bugs.php.net/bug.php?id=51788edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51788r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51788r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51788r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51788r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51788r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51788r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51788r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51788r=needscript Try newer version: http://bugs.php.net/fix.php?id=51788r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51788r=support Expected behavior: http://bugs.php.net/fix.php?id=51788r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51788r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51788r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51788r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51788r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51788r=dst IIS Stability: http://bugs.php.net/fix.php?id=51788r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51788r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51788r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51788r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51788r=mysqlcfg
Bug #51788 [Com]: Segfault on get_defined_constants(TRUE)
Edit report at http://bugs.php.net/bug.php?id=51788edit=1 ID: 51788 Comment by: whatrevolution at yahoo dot com Reported by: whatrevolution at yahoo dot com Summary: Segfault on get_defined_constants(TRUE) Status: Bogus Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.3.2 New Comment: Removing suhosin, xdebug, and recompiling apache, did in fact remove the bug behavior. Previous Comments: [2010-05-10 21:51:32] johan...@php.net Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. Suhosin and xdebug change the engine in a way we can't support. [2010-05-10 21:44:50] whatrevolution at yahoo dot com Description: get_defined_constants(TRUE) started throwing me segfaults today, for apparently no reason. Worked yesterday, doesn't work today. Test script does only that function and still throws back no data. I can't rule out server configuration, but I have tested for it somewhat, with same results. Apache mod_php5 produces the segfault. PHP CLI does not. bug 15614 Had this problem with print_r(get_defined_constants(TRUE)) in 2002. My segfault is happening with get_defined_constants(TRUE) alone. Ubuntu 10.04 Linux 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 PHP 5.3.2-1ubuntu4 with Suhosin-Patch (built: Apr 9 2010 08:18:14) Zend Engine v2.3.0 with Xdebug v2.0.5 with Suhosin v0.9.29 Apache/2.2.14 (Ubuntu) Test script: --- ?php print_r(get_defined_constants(TRUE)); Expected result: Function works. Actual result: -- [Mon May 10 15:08:44 2010] [notice] child pid 21884 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/bug.php?id=51788edit=1
Bug #51463 [Com]: ErrorException thrown from error_handler not catchable in exception handler
Edit report at http://bugs.php.net/bug.php?id=51463edit=1
ID: 51463
Comment by: whatrevolution at yahoo dot com
Reported by: tyra3l at gmail dot com
Summary: ErrorException thrown from error_handler not catchable
in exception handler
Status: Re-Opened
Type: Bug
Package: Scripting Engine problem
Operating System: Windows Xp Sp3, Debian Lenny
PHP Version: 5.3.2
New Comment:
OP's test code, result:
( ! ) Parse error: syntax error, unexpected T_FUNCTION, expecting ')' in
/var/www/php_bugs/exception_in_error_handler.php on line 13
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2010-04-02 15:19:15] tyra3l at gmail dot com
Another weird thing that I observed:
If I try to handle the fatal error from register shutdown function then
the error_get_last() will return NULL if I throw the ErrorException from
the error handler.
If I don't try to convert exceptions from errors, then the
error_get_last() will return the fatal error in the shutdown function.
Or if I generate fatal error for example with
new NonExistentClassName;
then the error_handler doesn't get called (because this is a fatal
error), but the shutdown function gets the fatal error with
error_get_last()
So it seems that there is some strange magic with this situation.
Tyrael
[2010-04-02 13:41:02] tyra3l at gmail dot com
But the exception handler should be called after the error handler and
before accessing the empty property which gives the fatal error, isn't
it?
I mean at first the interpreter tries to access the variable named $foo,
then generates a E_NOTICE which is trapped by the error handler, which
trows an Exception which never catched at all.
[2010-04-02 13:35:54] tyra3l at gmail dot com
shit, my mistake, $foo will be empty, so $this-$foo will be generating
a fatal error, but before that, generate a warning about $foo is empty.
:/
[2010-04-02 13:33:40] tyra3l at gmail dot com
On Lenny I was testing with the dotdeb.org 5.3.2 deb, on windows this is
the TS VC9 build
[2010-04-02 13:29:49] tyra3l at gmail dot com
Description:
It seems that there are some cases, when you can't catch Exceptions with
exception_handler which was thrown from error_handler for some errors.
For example if you do this:
$class = new StdClass;
echo $class-$foo;
error_handler gets called, ErrorException was thrown, but the Exception
wasn't catched with the exception_handler.
if you try
echo $foo;
instead of
echo $class-$foo;
then the same error gets called with the error handler (by same error,
I mean same parameters), but the Exception thrown in this case is
successfuly catched by the exception handler.
Test script:
---
?php
error_reporting(E_ALL);
ini_set('display_errors', 0);
function debug($s){
echo pre;
var_dump($s);
echo /pre;
}
set_error_handler(
function ($errno, $errstr, $errfile, $errline ) {
debug('error_handler');
debug(array(
'errno' = $errno,
'errstr'= $errstr,
'errfile' = $errfile,
'errline' = $errline,
));
throw new ErrorException($errstr, 0, $errno, $errfile,
$errline);
}
);
set_exception_handler(
function(Exception $e){
debug('exception_handler');
debug($e);
}
);
$class = new StdClass;
echo $class-$foo;
echo 'done';
Expected result:
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46)
}
string(17) exception_handler
object(ErrorException)#4 (8) {
[message:protected]=
string(23) Undefined variable: foo
...
Actual result:
--
string(13) error_handler
array(4) {
[errno]=
int(8)
[errstr]=
string(23) Undefined variable: foo
[errfile]=
string(55) C:\work\xampp_vc9\htdocs\default\bug\error_handling.php
[errline]=
int(46
Bug #47424 [Com]: not operator does a C cast to long which is different to other ops
Edit report at http://bugs.php.net/bug.php?id=47424edit=1
ID: 47424
Comment by: whatrevolution at yahoo dot com
Reported by: d_kelsey at uk dot ibm dot com
Summary: not operator does a C cast to long which is different
to other ops
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Linux 64Bit
PHP Version: 5.2CVS-2009-02-17 (CVS)
New Comment:
Bug OP's test, result:
int 9223372036854775807
int 9223372036854775807
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2009-02-17 14:05:01] d_kelsey at uk dot ibm dot com
Description:
In zend_operators.c the function ZEND_API int bitwise_not_function(..)
handles a double by doing a c cast to a long
if (op1-type == IS_DOUBLE) {
op1-value.lval = (long) op1-value.dval;
op1-type = IS_LONG;
}
but all other operators use the zendi_convert_to_long() macro
so not isn't consistent with the other operators.
this can result in an unexpected value as shown in the test case
Reproduce code:
---
?php
define(MAX_64Bit, 9223372036854775807);
$e = (MAX_64Bit + 1);
$f = (int)$e;
var_dump(~(MAX_64Bit + 1));
var_dump(~$f);
?
Expected result:
int(-9223372036854775808)
int(-9223372036854775808)
Actual result:
--
int(9223372036854775807)
int(-9223372036854775808)
--
Edit this bug report at http://bugs.php.net/bug.php?id=47424edit=1
Bug #47623 [Com]: array_shift() fails with @ operator
Edit report at http://bugs.php.net/bug.php?id=47623edit=1
ID: 47623
Comment by: whatrevolution at yahoo dot com
Reported by: Henry at huis-stijl dot nl
Summary: array_shift() fails with @ operator
Status: Verified
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-30)
New Comment:
?php
$_SESSION['villas'] = array
(
1 = array(1,2,3),
2 = array(2,3,4),
3 = array(3,4,5),
4 = array(4,5,6),
);
/*
* ONE:
*/
/*
While(@$_SESSION['villas'] != array())
{
$row = array_shift(@$_SESSION['villas']);
print_r($row);
}// einde while
*/
/*
* TWO:
*/
/*
while($foo['villas'] != array())
{
$row = array_shift(@$foo['villas']); // Removing @ makes it work..
var_dump($foo);
}
*/
/*
* THREE:
*/
//I cann bypass this failure by using:
$arr_temp = @$_SESSION['villas'];
$row = array_shift($arr_temp);
$_SESSION['villas'] = $arr_temp;
unset($arr_temp);
var_dump($_SESSION['villas']);
?
Result:
One and Two, same as described before.
Three:
array
0 =
array
0 = int 2
1 = int 3
2 = int 4
1 =
array
0 = int 3
1 = int 4
2 = int 5
2 =
array
0 = int 4
1 = int 5
2 = int 6
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2009-04-13 18:23:01] j...@php.net
This has nothing to do with sessions. Simplified script:
?php
$foo['villas'] = array('a','b','c');
while($foo['villas'] != array())
{
$row = array_shift(@$foo['villas']); // Removing @ makes it work..
var_dump($foo);
}
?
[2009-03-16 22:11:28] Henry at huis-stijl dot nl
Tried with and without the @ same output.
[2009-03-16 16:26:07] j...@php.net
If you remove those @'s, what does it output..?
[2009-03-11 14:07:22] Henry at huis-stijl dot nl
?php
session_start();
ini_set('session.cache_limiter', 'private');
// © 2009 Huis-stijl, Henry Hekman
$_SESSION['villas'] = array
(
1 = array(1,2,3),
2 = array(2,3,4),
3 = array(3,4,5),
4 = array(4,5,6),
);
While(@$_SESSION['villas'] != array())
{
$row = array_shift(@$_SESSION['villas']);
print_r($row);
}// einde while
?
on php 4 i get
Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 2 [1] = 3 [2] = 4
) Array ( [0] = 3 [1] = 4 [2] = 5 ) Array ( [0] = 4 [1] = 5 [2] =
6 )
on phph 5.2.9 i get a loop that doesnt end
Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1] = 2 [2] = 3
) Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1] = 2 [2] =
3 ) Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1] = 2 [2]
= 3 ) Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1] = 2
[2] = 3 ) Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1] =
2 [2] = 3 ) Array ( [0] = 1 [1] = 2 [2] = 3 ) Array ( [0] = 1 [1]
= 2 [2] = 3 ) Array ( [0] = 1 [1] = 2 [2] = 3 )
[2009-03-11 12:56:34] Henry at huis-stijl dot nl
Description:
Script was working perfectly on PHP 4 when updated to PHP5.2.9 I found
an error. I was filling a array in the session and looped it with
array_shift until the arry was empty.
This loop kept giving me the first value but did not erased it from te
original arry.
Reproduce code:
---
$row = array_shift(@$_SESSION['villas']);
Expected result:
1. $row getting the first element from $_SESSION['villas']
2. $_SESSION['villas'] to get lost the first element.
Actual result:
--
1. $row getting the first element from $_SESSION['villas']
2. $_SESSION['villas'] did not lost the first element and was unchanged
I cann bypass this failure by using:
$arr_temp = @$_SESSION['villas'];
$row = array_shift($arr_temp);
$_SESSION['villas'] = $arr_temp;
unset($arr_temp);
--
Edit this bug report at http://bugs.php.net/bug.php?id=47623edit=1
Bug #48255 [Com]: Mixing control structure syntaxes causes parse error
Edit report at http://bugs.php.net/bug.php?id=48255edit=1
ID: 48255
Comment by: whatrevolution at yahoo dot com
Reported by: faisun at sina dot com
Summary: Mixing control structure syntaxes causes parse error
Status: Verified
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-12)
New Comment:
Bug OP test, result:
( ! ) Parse error: syntax error, unexpected ':' in
/var/www/php_bugs/mixed_control_structure.php on line 5
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2009-05-13 04:05:30] faisun at sina dot com
Description:
PHP Version: 5.2.9.2
?
if(21):
echo ABCD;
if(43){ echo EFGH; }
else:
echo 123456;
endif;
?
Result: Parse error: parse error in E:\wwwroot\1.php on line 5
?
if(21):
echo ABCD;
if(43){ echo EFGH; } else{}
else:
echo 123456;
endif;
?
Result:ABCDEFGH
Reproduce code:
---
?
if(21):
echo ABCD;
if(43){ echo EFGH; }
else:
echo 123456;
endif;
?
Expected result:
ABCDEFGH
Actual result:
--
Parse error: parse error in E:\wwwroot\1.php on line 5
--
Edit this bug report at http://bugs.php.net/bug.php?id=48255edit=1
Bug #51397 [Com]: Math calculation bug
Edit report at http://bugs.php.net/bug.php?id=51397edit=1
ID: 51397
Comment by: whatrevolution at yahoo dot com
Reported by: emanuel dot dejanu at humaninfo dot ro
Summary: Math calculation bug
Status: Verified
Type: Bug
Package: Scripting Engine problem
Operating System: FREEBSD LINUX
PHP Version: 5.2.13
New Comment:
My answer to myhash('CL6.1.7'): 229416432419738
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2010-03-26 11:56:42] f...@php.net
Verified with 5.2.13 on Debian (default configure)
Verified in the Debian 5.2.6+lenny4 PHP (just for completeness)
Correct result with 5.3.2 on Gentoo
[2010-03-26 08:20:19] emanuel dot dejanu at humaninfo dot ro
Description:
I have used the code from the test script on my development machine
(Windows Professional 7 32bit) with php 5.2.12 and is working correctly
but when I have deployed on my production machine that is FreeBSD 6.3
32bit with the same php version 5.2.12 is giving wrong results
(-2147483593). I also run this on other production machine that is
RedHat 5 32bit with php 5.2.6 and is also giving wrong results
(-2147483593).
I can not test with php 5.2.13 on production machines (virtual
hosting).
On windows is giving the correctly result (754303898) with PHP 5.2.12
and PHP 5.3.1. I am running in 32bit platform on all machines.
---
PHP_INT_SIZE: 4
System = FreeBSD somehost.com 6.3-RELEASE FreeBSD 6.3-RELEASE #6: Wed
Oc
t 21 09:32:42 MDT 2009 r...@fc:/usr/src/sys/i386/compile/VKERN i386
Build Date = Mar 3 2010 12:51:00
Configure Command = './configure' '--with-layout=GNU'
'--with-config-file-sca
n-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml'
'--with-libxml-dir=/
usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi'
'--with-
apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/
usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=i386-
portbld-freebsd6.3'
Server API = Command Line Interface
Virtual Directory Support = disabled
Configuration File (php.ini) Path = /usr/local/etc
Loaded Configuration File = /usr/local/etc/php.ini
Scan this dir for additional .ini files = /usr/local/etc/php
additional .ini files parsed = /usr/local/etc/php/extensions.ini
PHP API = 20041225
PHP Extension = 20060613
Zend Extension = 220060519
Debug Build = no
Test script:
---
function myhash($key) {
$h = 5381;
$l = strlen($key);
for($i = 0; $i $l; ++$i) {
$h = (($h 5) + $h) ^ ord($key[$i]);
}
return $h;
}
$h = myhash('CL6.1.7');
if ($h != 754303898)
echo bug\n;
echo $h . \n;
Expected result:
754303898
Actual result:
--
bug
-2147483593
--
Edit this bug report at http://bugs.php.net/bug.php?id=51397edit=1
Bug #51506 [Com]: Realpath failed on linux Server for version 5.2.10 ?
Edit report at http://bugs.php.net/bug.php?id=51506edit=1 ID: 51506 Comment by: whatrevolution at yahoo dot com Reported by: mastershepper at gmail dot com Summary: Realpath failed on linux Server for version 5.2.10 ? Status: Open Type: Bug Package: Apache2 related Operating System: Linux PHP Version: 5.2.13 New Comment: Code: ?php var_dump( realpath( dirname( __FILE__ ) ) ); echo \n; var_dump( realpath( '../' ) ); echo \n; var_dump( realpath( '../../' ) ); ? Result: string '/var/www/php_bugs' (length=17) string '/var/www' (length=8) string '/var' (length=4) PHP Version 5.2.10-2ubuntu6.4 System Linux 2.6.31-20-generic x86_64 Build Date Jan 6 2010 22:36:47 Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled Apache/2.2.12 (Ubuntu) Previous Comments: [2010-04-09 09:51:02] mastershepper at gmail dot com Hi, the php version is now up to date (5.2.13) and still have the problem. I tried many realpath(), the absloute path of the web directory ios the following one : /home/.sites/38/site52/web I thought that realpath( '/home/.sites/38/site52/web' ) should works fine, but it return me false, like any other realpath I'm asking (like realpath( '/' ) which is working well on my IIS environment). I also tried to set the include path with this line : set_include_path(get_include_path() . PATH_SEPARATOR . '/home/.sites/38/site52/web'); But it still not working fine. Is there anything I missed ? I'm probably wrong but I don't see where. Thanks for your help. [2010-04-08 11:15:41] paj...@php.net You can test locally as well, or in a VM using the same linux version that you have on your prod server. [2010-04-08 11:12:25] mastershepper at gmail dot com __FILE__ is just a test, the actuel drupal core use realpath on dynamic paths and it always return false. The actual production environment is an external one so I'm not able to change the php version. I will ask for it and update this report when it will be done (only if it could be done, unfortunately) Thanks for your help. [2010-04-08 11:02:07] paj...@php.net __FILE__ is already an absolute path, I don't see why you would do that in the 1st place. However, if you can reproduce the realpath problem with other paths as well, then I suspect a bug on your linux version. Can you try with 5.2.13 pls? [2010-04-08 10:47:47] mastershepper at gmail dot com Description: hi, I met an issue using a drupal CMS. I received an error warning: move_uploaded_file() [function.move-uploaded-file]: Unable to access in /home/.sites/38/site52/web/includes/file.inc on line 572. I have several web environement, one for coding the website (with IIS 6 and PHP 5.2.3), on for production (with Linux, Apache 2.0 and PHP 5.2.10). I have no issue on my development server with IIS (same files, same database). when I run the following line of code : var_dump( realpath( dirname( __FILE__ ) ) ); Under IIS: string(44) D:\inetpub\vhosts\dev.***.com\httpdocs Under Apache: bool(false) Did I miss something ? Best regards, Denis. Test script: --- var_dump( realpath( dirname( __FILE__ ) ) ); Expected result: I wish that this function gives me the real path to let drupal copy some files from the administration. -- Edit this bug report at http://bugs.php.net/bug.php?id=51506edit=1
Bug #51363 [Com]: Fatal error raised by var_export() not caught by error handler
Edit report at http://bugs.php.net/bug.php?id=51363edit=1
ID: 51363
Comment by: whatrevolution at yahoo dot com
Reported by: daan at react dot com
Summary: Fatal error raised by var_export() not caught by error
handler
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian Etch
PHP Version: 5.2.13
Assigned To: derick
New Comment:
I am curious if the bug OP expects the var_export() output to never
end... ever? I do, because it is a recursive reference, so I'm puzzled
that this is considered a bug.
However, perhaps the solution would be to not throw a fatal error, but
throw a notice or warning and/or provide some way of telling
var_export() how deep to print.
array ( 0 = array ( 0 = array ( 0 = array ( 0 = array (
( ! ) Fatal error: Nesting level too deep - recursive dependency? in
/var/www/php_bugs/var_export_recursion_test.php on line 36
Call Stack
# TimeMemory FunctionLocation
1 0.0004 108776 {main}( ) ../var_export_recursion_test.php:0
2 0.0004 109968 var_export ( ) ../var_export_recursion_test.php:36
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
Previous Comments:
[2010-03-23 12:58:59] daan at react dot com
Description:
When a fatal error is raised by var_export() when trying to export a
resursive array, it is not caught by a user php error handler.
Test script:
---
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
var_dump($errno, $errstr, $errfile, $errline);
/* Don't execute PHP internal error handler */
return true;
}
set_error_handler(myErrorHandler);
$recursive = array();
$recursive[] = $recursive;
var_export($recursive);
Expected result:
The var_dumped variables
Actual result:
--
array ( 0 = array ( 0 = array ( 0 = array ( 0 = array (
Fatal error: Nesting level too deep - recursive dependency? in test.php
on line x
--
Edit this bug report at http://bugs.php.net/bug.php?id=51363edit=1
