Handy tracebacks instead of uninformative segfaults¶

Tags: django, python

Because we make geographical websites, we use a lot of C libraries (often via a Python wrapper). Pyproj/proj, gdal, that sort of stuff. And sometimes something goes wrong:

$ bin/test
nosetests --verbosity 1 lizard_ocean
Segmentation fault      bin/test

Wow, that’s not very informative.

Lately someone pointed me at faulthandler. Simply enable it and you get much handier tracebacks instead of a a plain segfault. So I added this to my Django settings file:

import faulthandler
faulthandler.enable()

And now the bin/test output is waaaaay better:

$ bin/test
nosetests --verbosity 1 lizard_ocean
Fatal Python error: Segmentation fault

Current thread 0x00007f10653ae700:
  File "/usr/lib/python2.7/dist-packages/pyproj/__init__.py", line 164 in __new__
  File "some_where/lizard_map-4.28-py2.7.egg/lizard_map/coordinates.py", line 45 in <module>
  File "some_where/lizard_map-4.28-py2.7.egg/lizard_map/views.py", line 41 in <module>
  File "/vagrant/sites/adoos/src/lizard-ocean/lizard_ocean/views.py", line 8 in <module>
  File "/vagrant/sites/adoos/src/lizard-ocean/lizard_ocean/urls.py", line 12 in <module>
  File "some_where/nose-1.2.1-py2.7.egg/nose/importer.py", line 86 in importFromDir
  File "some_where/nose-1.2.1-py2.7.egg/nose/importer.py", line 39 in importFromPath
  File "some_where/nose-1.2.1-py2.7.egg/nose/loader.py", line 390 in loadTestsFromName
  File "some_where/nose-1.2.1-py2.7.egg/nose/loader.py", line 163 in loadTestsFromDir
  File "some_where/nose-1.2.1-py2.7.egg/nose/loader.py", line 327 in loadTestsFromModule
  File "some_where/nose-1.2.1-py2.7.egg/nose/loader.py", line 405 in loadTestsFromName
  File "/usr/lib/python2.7/unittest/loader.py", line 128 in loadTestsFromNames
  File "some_where/nose-1.2.1-py2.7.egg/nose/loader.py", line 453 in loadTestsFromNames
  File "some_where/nose-1.2.1-py2.7.egg/nose/core.py", line 183 in createTests
  File "some_where/nose-1.2.1-py2.7.egg/nose/core.py", line 169 in parseArgs
  File "/usr/lib/python2.7/unittest/main.py", line 94 in __init__
  File "some_where/nose-1.2.1-py2.7.egg/nose/core.py", line 118 in __init__
  File "some_where/django_nose-1.1-py2.7.egg/django_nose/runner.py", line 117 in run_suite
  File "some_where/django_nose-1.1-py2.7.egg/django_nose/runner.py", line 155 in run_tests
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/commands/test.py", line 72 in handle
  File "some_where/South-0.7.6-py2.7.egg/south/management/commands/test.py", line 8 in handle
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/base.py", line 232 in execute
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/base.py", line 196 in run_from_argv
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/commands/test.py", line 49 in run_from_argv
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/__init__.py", line 382 in execute
  File "some_where/Django-1.4.5-py2.7.egg/django/core/management/__init__.py", line 459 in execute_manager
  File "some_where/djangorecipe-1.5-py2.7.egg/djangorecipe/test.py", line 19 in main
  File "bin/test", line 45 in <module>
Segmentation fault      bin/test

The top of the traceback in this case informs me that “pyproj” (and/or the actual C “proj” library) is the source of the problem. Now I’ve got something to debug!

Reinout van Rees

My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.

Weblog feeds

Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):