php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #30471 var_export: Nesting level too deep - recursive dependency?
Submitted: 2004-10-18 17:33 UTC Modified: 2004-11-15 20:19 UTC
Votes:2
Avg. Score:2.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: none at example dot com Assigned: derick (profile)
Status: Not a bug Package: PHP options/info functions
PHP Version: 5.0.2 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
 [2004-10-18 17:33 UTC] none at example dot com 
Description:
------------
doing var_export( $GLOBALS, true ) there is an error 
like in older versions of php4:

Nesting level too deep - recursive dependency?

Of course it is easy to do a workaround, but maybe it 
would be nice to fix it. Theres a lot of discussion 
araound this bug in some communities for older php 
versions. Maybe it is me being in error or maybe this is 
just a feature and not a bug? In this case sorry for 
disturbing...

Thanks a lot for all your work!


Reproduce code:
---------------
<?php

$outText = var_export( $GLOBALS, true );

?>

Expected result:
----------------
I would expect to get var_export in $outText

Actual result:
--------------
array (  'GLOBALS' => array (  'GLOBALS' => array (  
'GLOBALS' => array ( 
Fatal error: Nesting level too deep - recursive 
dependency?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-15 20:19 UTC] derick@php.net 
There is no way to return a correct output in this case, so this is not a bug but expected behavior.
 [2010-06-27 05:55 UTC] jdickey at seven-sigma dot com 
Derick, I'd suggest that that "expected behavior" itself is a design flaw in the 
PHP interpreter. The solutions I can think of right off would be ugly, granted 
(special-case check for global-variable accessor to detect whether it's attempting 
to recurse as an effect of debug_backtrace() and, if so, throw an exception that 
can then be caught by d_bt); I find it really hard to believe that such a heavily-
used software platform with such a large, competent company and community behind 
it can't come up with a better solution.

Marking this bug as 'bogus' merely insults your developer customers and encourages 
them to go find a real language instead.
 [2010-10-28 20:49 UTC] hendy at soluvas dot com 
This bug is VALID!

The following code works:

var_dump($GLOBALS);

Therefore the dumping algorithm is inconsistent. var_export() should just use the same algorithm as var_dump().
 [2011-03-26 15:21 UTC] ricki at rocker dot com 
I don't believe this is a bug as the purposes of var_dump and var_export are 
entirely different:

var_dump - simply dumps a readable form 
var_export - exports valid PHP! This code is actually usable within an 
application.

var_dump therefore can "manage" the recursive nature of global by simply doing 
the following in the output
&array(15) {
        ["GLOBALS"]=>
        *RECURSION*

var_export on the other hand clearly can't take the same approach to recursion 
if the generated PHP output is to work as intended by the application designer. 
- it can only (and should only) fail.

hope this is useful to someone.
 [2012-03-28 05:48 UTC] jodybrabec at gmail dot com 
WORKAROUND:
ob_start();
var_dump($GLOBALS);
$dataDump = ob_get_clean();
 [2012-06-27 16:03 UTC] oxygenus at gmail dot com 
var_export should receive a third param with a flag to detect recursivness and set 
NULL [or some special value such as an instance of an object of class 
RecursiveError].
 [2013-03-25 17:46 UTC] patrick at infranet dot com 
Another option would be to have var_export always produce some output and then 
limit the output to some level of recursion (settable by user, but defaulting to 
some minimum safe but useful value).
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Mar 28 18:01:31 2025 UTC