This page collects tips that might make debugging Launchpad a little easier. They're presented in no particular order -- please add yours!. All pages dedicated to testing can be found in CategoryTesting. |
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.
Getting past "LocationError: 'json'" in TAL template tracebacks
If you're testing with a new TAL template (.pt file) and you get nasty-looking tracebacks that says something about
LocationError: (<lazr.restful.tales.WebLayerAPI object at 0xd932ccc>, 'json')
then 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 that way.
Using iharness for digging error tracebacks
If you are reading this, most probably you have noticed that when things get wrong, ZOPE and TAL will rather give you a pointless LocationError without to much information about what is causing it.
To find out what exactly went wrong you can use make iharness and investigate that specific LocationError
Let's say that you got this error for language_translation_statistics:
LocationError: (<zope.browserpage.metaconfigure.SimpleViewClass from PATH_TO_TEMPLATE/template.pt object at 0xcf60fec>, 'language_translation_statistics')
To start the testing/debugging environment (the harness) run:
make iharness
Next you will have to import your classed and get your object. In our example we were trying to get the PerLanguageStatisticsView for ubuntu['hoary'] series.
from canonical.launchpad.webapp.servers import LaunchpadTestRequest from lp.our.module import PerLanguageStatisticsView #create and initialize the view ubuntu = getUtility(ILaunchpadCelebrities).ubuntu view = PerLanguageStatisticsView (ubuntu['hoary'], LaunchpadTestRequest()) view.initialize() #request the view key key = view.language_translation_statistics
Now you should see a more meaningful message.