Forums / Cotonti / Core Labs / Archive / Debugging facilities

Some improvements to make life easier

Trustmaster
#1 2009-04-28 16:43
I think that making error messages more verbose and adding such debugging facilities like backtrace, variable dumps and breakpoints could help developers a lot.

I use XDebug for local debugging but you can't use it on a real website.

If you'd like to request some features related to debugging, post them below.
May the Source be with you!
Orkan
#2 2009-04-28 22:11
It is possible to use XDebug on a real site. You can even render the XDebug stack within a web page.

Check out the Web Debug Toolbar from Symfony - I found it very useful :)
Perl - the only language that looks the same before and after RSA encryption.
Elgan
#3 2009-04-28 23:17
this sounds interesting. As i have never ever actually used a debugging, In php. Other than rereading the script. im It could be quite useful.
Trustmaster
#4 2009-04-28 23:32
That might be quite funny using XDebug on a production server is what I meant. Sidenote: using XDebug with NetBeans.

I just thought XDebug or ZendDebugger is not always available to everyone, so having simple debugging tools available in CMF could help. OFC, it doesn't allow you real breakpoints (with play/pause, etc.) or watches, but still obviously better than "OOPS, me crashed, read the code again from the very beginning".
May the Source be with you!
Orkan
#5 2009-04-29 03:01
Ahh, I thought you're saying that it isnt possible to use XDebug through the web interface (only in external tools like NetBeans or Eclipse...)

Yah, debugging on a production server isnt the best practice :p
Anyway, it could be nice to have XDebug stack trace displayed on each server halt, like Symfony has, with last DB query used. MySQL error messages are the most irritating, they never show which query is causing problems. The most extreme example is something like: Error at ''

PS. XDebug and Target Management for Eclipse (vid)
Perl - the only language that looks the same before and after RSA encryption.
This post was edited by Orkan (2009-04-29 03:07, 14 years ago)
Kilandor
#6 2009-04-29 06:23
Eh i'm used to just doing everything the manual way, Echo this that, print this array, etc etc.
Trustmaster
#7 2009-04-29 12:25
That MySQL puzzle is solved by adding backtrace to sed_diefatal(). Any more wishes?

OK, I've added a few simple functions which make manual debugging easier:
  • sed_assert($var1,..) - use it to print variables on a blank screen immediately
  • sed_backtrace() - prints backtrace (files, functions, parameters). By default blanks the screen, call sed_backtrace(FALSE) to see backtrace within normal output flow.
  • sed_vardump() - attempts to print contents of all global variables recursively. Doesn't print all of them because it has length limitation. By default blanks the screen, call sed_vardump(FALSE) to see vardump within normal output flow.

sed_diefatal() was modified and a new option was added to config.php:
/**
 * Defines whether to display debugging information on critical errors.
 * Comment it on production sites if you wish.
 */
define('SED_DEBUG', TRUE);
By default this switch is on. On some production sites you'd like to disable it because debug info contains file paths. When this switch is defined, sed_diefatal() prints backtrace. It is extremely useful to track MySQL errors.
May the Source be with you!
This post was edited by Trustmaster (2009-05-03 17:41, 14 years ago)
GHengeveld
#8 2009-05-03 23:22
Why enable it by default? I think most users will not look at this during installation and thus introduce this (minor) security hole).
Trustmaster
#9 2009-05-04 01:20
SQL errors don't normally happen, they usually happen when testing new things. But if you insist, I can disable it by default. However, I'm afraid most will forget to enable it while debugging so it will be useless.
May the Source be with you!