Debugging

Not logged in - Log In / Register

Revision 19 as of 2010-01-12 21:45:44

Clear message

This page collects tips that might make debugging Launchpad a little easier. They're presented in no particular order -- please add yours!

Getting Better Tracebacks

If you get nasty-looking tracebacks when testing your local development instance via the web browser -- tracebacks that seem to have no relationship to the code changes you made -- try visiting the corresponding URL in the web services API.

For example, if https://bugs.launchpad.dev/redfish gets an unwieldy traceback, then try https://launchpad.dev/api/beta/redfish instead; you'll often get a much more comprehensible error trace.

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.


CategoryTipsAndTricks