Debugging

Debugging

Bricolage is a complex application and debugging can be difficult. Here are some tips to help you find bugs faster:

• Turn on QA_MODE in your bricolage.conf file. This will cause the UI to display a bunch of useful data at the bottom of every page, including session state, cache state, cookies, and GET and POST args. QA_MODE turns on PerlWarn (use warnings) and causes error messages to include more information. QA_MODE also enables Apache::Status at the URL /perl-status which allows you can to examine the state of the Perl interpreter inside Apache.

• Set the NO_TOOLBAR directive to “0” or “Off” in bricolage.conf to keep Bricolage from popping up a new browser window without a toolbar.

• Run Bricolage under the Perl debugger using the debug command with bric_apachectl:

bric_apachectl debug

This will start Apache in single-process mode (httpd -X) and setup Apache::DB to start the debugger on the each hit to the server. You’ll need to install the Apache::DB Perl module to use this command. To run Bricolage under DDD, start ddd as root and load bin/bric_apachectl. Give it the argument “debug” and run it. When you issue a hit to the server the debugger will stop on the first line of Bric::App::Handler::handler(). From there you can set breakpoints inside Bricolage and debug normally. If you prefer to run without the debugger using only the Apache single-process mode, then run Bricolage using the command

bric_apachectl single

• Set DBI_DEBUG and DBI_CALL_TRACE to 1 in your bricolage.conf file. DBI_DEBUG records every database call in the logs complete with SQL and arguments. DBI_CALL_TRACE adds a a subroutine call trace for each statement showing where the database call originated. This generates a lot of data but it can be very helpful.

• Look at the database directly using psql. Many bugs in Bricolage can only be successfully diagnosed by examining records created in the database.