Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Bricolage is a complex application and debugging can be difficult. Here are some tips to help you find bugs faster:
- Turn on
bricolage.conffile. 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.
use warnings) and causes error messages to include more information.
Apache::Statusat the URL
/perl-statuswhich allows you can to examine the state of the Perl interpreter inside Apache.
- Set the
NO_TOOLBARdirective to “0” or “Off” in
bricolage.confto 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 debugThis will start Apache in single-process mode (
httpd -X) and setup
Apache::DBto start the debugger on the each hit to the server. You’ll need to install the
Apache::DBPerl module to use this command. To run Bricolage under DDD, start
dddas 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
DBI_CALL_TRACEto 1 in your
DBI_DEBUGrecords every database call in the logs complete with SQL and arguments.
DBI_CALL_TRACEadds 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.