launchpad development|
Size: 1419
Comment: New page, initialized from the soon-to-be-former "Tips and Tricks" page.
|
Size: 3977
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #FORMAT rst =================== Debugging Launchpad =================== |
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
| Line 9: | Line 5: |
Debugging stories/pagetests =========================== |
= Debugging stories/pagetests = |
| Line 17: | Line 11: |
| Just add this at the point where your pagetest is failing:: | Just add this at the point where your pagetest is failing: |
| Line 19: | Line 13: |
| {{{ | |
| Line 20: | Line 15: |
| }}} | |
| Line 21: | Line 17: |
| This is just a convenience wrapper around ``pdb.set_trace()`` except that it also redirects stdout back to your console. When your pagetest hits this line, you'll be dropped into the debugger. Now, go to a different shell and type:: | This is just a convenience wrapper around ``pdb.set_trace()`` except that it also redirects stdout back to your console. When your pagetest hits this line, you'll be dropped into the debugger. Now, go to a different shell and type: |
| Line 23: | Line 19: |
| {{{ | |
| Line 24: | Line 21: |
| }}} | |
| Line 26: | Line 24: |
== Debugging With GDB == Some kinds of bugs (segfaults, hung processes, out-of-control daemons) are hard to debug from within Python. See Debugging/GDB for how to debug them. == Special URLs == Launchpad provides special URLs that can be used to help with debugging. || ''URL element'' || ''Description'' || || ``++oops++`` || record an OOPS report while still rendering the page correctly. The OOPS id is provided in the HTML source code || || ``++debug++error`` || XXX: fill in description || || ``++debug++tal`` || show the TAL declarations in the HTML source code || || ``++debug++source`` || show path to templates for a given view || || ``++form++`` || XXX: fill in description || Some of those can combined, like: ++debug++tal,source Examples -------- https://launchpad.dev/++oops++ https://launchpad.dev/++debug++tal https://launchpad.dev/++debug++source https://launchpad.dev/++debug++error - XXX: returns an OOPS https://launchpad.dev/++form++ - XXX: returns a 404 = Tracing SQL statements through STORM = `from storm.tracer import debug; debug(True)` This will cause all statements run by Storm to be written to stderr. `debug(False)` disables this behaviour. This is useful when optimising pages to run fewer queries, as you can see exactly when and what is executed rather than pulled from cache. Alternative to this is to set LP_DEBUG_SQL=1 environment variable before running `make harness` or `make run` (or LP_DEBUG_SQL_EXTRA=1 to get tracebacks for every query execution). = Tracing SQL statements with PostgreSQL = Statement logging can be configured in `postgresql.conf`, by setting `log_statement` to one of `none`, `ddl`, `mod` or `all` ([[http://www.postgresql.org/docs/8.3/static/runtime-config-logging.html#GUC-LOG-STATEMENT|docs]]). The server needs to be reloaded (by `SIGHUP` or `pg_ctl reload`) for changes to take effect. It can also be set for a session, user or database: ` SET log_statement TO 'all'; -- `([[http://www.postgresql.org/docs/8.3/static/sql-set.html|docs]]) ` ALTER ROLE launchpad SET log_statement TO 'all'; -- `([[http://www.postgresql.org/docs/8.3/static/sql-alterrole.html|docs]]) ` ALTER DATABASE launchpad_dev SET log_statement TO 'all'; -- `([[http://www.postgresql.org/docs/8.3/static/sql-alterdatabase.html|docs]]) Once enabled, statements will be logged to `/var/log/postgresql/postgresql-*-main.log`. ---- CategoryTipsAndTricks |
This page collects tips that might make debugging Launchpad a little easier. They're presented in no particular order -- please add yours!
Debugging stories/pagetests
Debugging stories (a.k.a. pagetests) can be kind of a pain because they build up state as they go. So if a test fails down deep in the doctest, and you want to see what the page really looks like at that point, you'd normally have to manually click through each step in the doctest until you get to the place that's broken.
But there's an easier way!
Just add this at the point where your pagetest is failing:
>>> stop()
This is just a convenience wrapper around pdb.set_trace() except that it also redirects stdout back to your console. When your pagetest hits this line, you'll be dropped into the debugger. Now, go to a different shell and type:
% make LPCONFIG=testrunner run
This starts up the appserver, except that it will use the testrunner configuration. What's cool about that is that this configuration attaches to the same database as the pagetest you're now stopped inside of. Meaning, all that state your doctest has built up, is available to your browser. So just hit the URL of the page that your doctest is failing on, and see it in all it's wondrous, albeit borked, glory.
Debugging With GDB
Some kinds of bugs (segfaults, hung processes, out-of-control daemons) are hard to debug from within Python. See Debugging/GDB for how to debug them.
Special URLs
Launchpad provides special URLs that can be used to help with debugging.
URL element |
Description |
++oops++ |
record an OOPS report while still rendering the page correctly. The OOPS id is provided in the HTML source code |
++debug++error |
XXX: fill in description |
++debug++tal |
show the TAL declarations in the HTML source code |
++debug++source |
show path to templates for a given view |
++form++ |
XXX: fill in description |
Some of those can combined, like: ++debug++tal,source
Examples
https://launchpad.dev/++oops++
https://launchpad.dev/++debug++tal
https://launchpad.dev/++debug++source
https://launchpad.dev/++debug++error - XXX: returns an OOPS
https://launchpad.dev/++form++ - XXX: returns a 404
Tracing SQL statements through STORM
from storm.tracer import debug; debug(True)
This will cause all statements run by Storm to be written to stderr. debug(False) disables this behaviour.
This is useful when optimising pages to run fewer queries, as you can see exactly when and what is executed rather than pulled from cache.
Alternative to this is to set LP_DEBUG_SQL=1 environment variable before running make harness or make run (or LP_DEBUG_SQL_EXTRA=1 to get tracebacks for every query execution).
Tracing SQL statements with PostgreSQL
Statement logging can be configured in postgresql.conf, by setting log_statement to one of none, ddl, mod or all (docs). The server needs to be reloaded (by SIGHUP or pg_ctl reload) for changes to take effect.
It can also be set for a session, user or database:
SET log_statement TO 'all'; -- (docs)
ALTER ROLE launchpad SET log_statement TO 'all'; -- (docs)
ALTER DATABASE launchpad_dev SET log_statement TO 'all'; -- (docs)
Once enabled, statements will be logged to /var/log/postgresql/postgresql-*-main.log.
