Unwanted recursion during trace command

[Morten Poulsen]

Hello

Working on firephp integration in my cms of choice I tried to allow tracing of to be selected as an option. But running this cause an error like seen below with the recursion error repeating MANY times (100 I guess, didn't count). Any idea what's causing this? The page takes a long time to load, but when loaded the output in firebug consolse makes sense and is an actual trace.

Another thing about tracing, is there a way, or could there be, to give a command like "trace but stop on this step, or the step behind". As I wrap the firephp in a module, the last 3 lines in the trace is concerning the wrapping, and is not interesting for the developer. Just an idea.

Hope you can help with the recursion-error.

Regards
Morten Poulsen


Warning: [json] (json_encode_r) type is unsupported, encoded as null. in C:\wamp\www\cms1\modules\FirePHPDebug\firephp\lib\FirePHPCore\FirePHP.class.php on line 827

Warning: json_encode() [function.json-encode]: recursion detected in C:\wamp\www\cms1\modules\FirePHPDebug\firephp\lib\FirePHPCore\FirePHP.class.php on line 827

Warning: json_encode() [function.json-encode]: recursion detected in C:\wamp\www\cms1\modules\FirePHPDebug\firephp\lib\FirePHPCore\FirePHP.class.php on line 827

Warning: json_encode() [function.json-encode]: recursion detected in C:\wamp\www\cms1\modules\FirePHPDebug\firephp\lib\FirePHPCore\FirePHP.class.php on line 827

[Christoph Dorn]

The warnings you are getting are most likely due to the fact that you are logging too much data. This is a common problem when working with frameworks. FirePHP detects and breaks recursion but for some reason json_encode() still chokes when logging a lot of data.

You can use the object filter feature of the FirePHPCore library to get around this problem:

$firephp->setObjectFilter('ClassName',
                           array('MemberName'));

See: http://www.firephp.org/HQ/Use.htm

Using this method you can exclude specific object members from being logged. Look at the classes in your framework and try to determine which object members contain references to other objects that are not really of any interest to you when debugging. Excluding members not required during debugging will dramatically reduce the amount of data logged.

Let me know if this solves your problem.

There is a ticket concerning the ability to exclude wrapping code from appearing in traces. Feel free to add your comments: http://code.google.com/p/firephp/issues/detail?id=62

At this time you cannot limit the number of steps in a backtrace. Please file a ticket to add this feature.

[Morten Poulsen]

Hi Christoph

Thank you for your reply! The strange thing is, that I don't log anything, I simply issue a trace-command within a function in a module of the cms. I've checked that the function is not recursing by itself, and it is only called once, but the trace command still results in the recursion. I'm currently using any log-commands, or any other firephp-functions, anywhere else in the code, solely the trace.

Any suggestions I can try? I've tried switching between native/module json-encode, but that only makes it even slower.

The logging capabilities are functioning perfect, though. And as soon as I polish up the debugging module I may apply for inclusion on the wiki-page of framework-integration.

Best regards
Morten Poulsen

[Morten Poulsen]

Perhaps I should mention that the console output after loading the page with the huge amount of warning, is perfectly allright. See here:

CMSms Statistics: We're into Firedebugging!
File Line Instruction
C:\wamp\www\cms1\modules\FirePHPDebug\FirePHPDebug.module.php
       
144
       
FirePHP->trace( 'CMSms Statistics: We're into Firedebugging!')
C:\wamp\www\cms1\modules\Statistics\Statistics.module.php
       
1832
       
FirePHPDebug->ConsoleMessage( 'Statistics', 'We're into Firedebugging!', 'trace', array())
C:\wamp\www\cms1\modules\Statistics\action.defaultadmin.php
       
6
       
Statistics->FireDebug( 'We're into Firedebugging!', 'trace')
C:\wamp\www\cms1\lib\classes\class.module.inc.php
       
1551
       
include( 'C:\wamp\www\cms1\modules\...s\action.defaultadmin.php')
C:\wamp\www\cms1\lib\classes\class.module.inc.php
       
1588
       
CMSModule->DoAction( 'defaultadmin', 'm1_', array('action'=>'defaultadmin'), '')
C:\wamp\www\cms1\admin\moduleinterface.php
       
137
       
CMSModule->DoActionBase( 'defaultadmin', 'm1_', array())

[Christoph Dorn]

You don't need to log anything. Issuing a trace command is enough for FirePHP to log all method arguments that appear in the stack trace.

Open the stack trace in the Firebug console and mouse-over some of the method arguments. Find one that takes a long time to render and see if you can identify some object members that are not needed.

Add a filter for these and then try again. Everything should work much batter and faster.

[Tobias Meier]

Hi! I'm having the same Problem with traces and I think it may be the FirePHP methods which are too big, all other Params I use are some strings. Btw: I wonder why the FirePHP methods are also listed in the trace anyway.
I did FB::setObjectFilter('FirePHP',array('instance','objectStack')); but it had no effect. Do you maybe have some hint how to get rid of that warning other than placing an '@' in line 970 of FirePHP.class.php ;)

[Christoph Dorn]

FirePHP methods should be excluded automatically. If the FirePHPCore library is used via a wrapper some methods may make it into the call stack at this time.

The only way the objectStack property will cause problems is if you are logging objects with a reference to the FirePHP class. I have added a ticket to ensure objectStack is filtered out in this case: http://code.google.com/p/firephp/issues/detail?id=122

To figure out what is causing the issue you need to look at the logged data in Firebug or the headers if the data is not displaying. Then trace it back to to the object being logged and filter out properties that are not required.