Don't crash PuDB when viewing an object with a buggy str() or repr(). #36

merged 1 commit into from Apr 12, 2012


None yet

3 participants

pvaret commented Apr 12, 2012


Currently PuDB can crash when using the str or repr stringifiers, if the object being stringified is buggy. When attempting to debug code, it's very much a pain.

This patch works around the issue by falling back to the type stringifier in case the str or repr one fails.

inducer commented Apr 12, 2012

@asmeurer, can you take a quick a look at this, please?


It works for me. I created a file

class Test(object):
    def __str__(self):
        raise Exception

a = Test()

In master, it fails with

Traceback (most recent call last):
  File "/sw/lib/python2.7/", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/sw/lib/python2.7/", line 72, in _run_code
    exec code in run_globals
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 36, in <module>
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 30, in main
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 67, in runscript
    dbg.interaction(None, sys.exc_info())
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 206, in interaction
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 157, in set_frame_index
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 1433, in update_var_view
    locals, globals)
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 461, in make_var_view
    tmv_walker.walk_value("", var, locals[var])
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 257, in walk_value
    displayed_value = get_stringifier(iinfo)(value)
  File "/Users/aaronmeurer/Documents/pudb/pudb/", line 235, in <lambda>
  File "/Users/aaronmeurer/Documents/pudb/", line 81, in pudb_stringifier
    return run_with_timeout("str(obj)", 0.5, {'obj':obj})
  File "/Users/aaronmeurer/Documents/pudb/", line 69, in run_with_timeout
    r = eval(code, globals)
  File "<string>", line 1, in <module>

but in this branch, the string form gives a: Test (!! ~/Documents/pudb/ error !!).

@inducer inducer merged commit 8c6fe86 into inducer:master Apr 12, 2012
inducer commented Apr 12, 2012

Sounds good. Thanks, both of you!


By the way, another option would be to catch the exception with pudb itself. I've never had __str__ raise an exception while debugging, so I don't know if this would be more desirable.

inducer commented Apr 13, 2012

On the one hand, that would be neat--on the other, at that point, there'd be half of pudb on the stack, which might or might not confuse people...

pvaret commented Apr 13, 2012

An option to debug the buggy str() or repr() from within PuDB
would be terrific, but wouldn't it be awfully complicated to implement?

I mean, in this case, the exception isn't occurring from within the flow
of the program being debugged. So at the least, we'd have to push
PuDB's frame stack onto the program's, which, well, might confuse things.

What I did to debug my repr (after patching PuDB so it wouldn't crash)
was simply to add an explicit call to repr(my_object) in my program,
just after the pudb.set_trace() call. So, hmm. How complicated would it
be to let stringifier exceptions bubble up, push a
repr(problematic_object) (or str) onto the program's stack, and trace

inducer commented Apr 13, 2012

Meh, too much effort. :)


Yeah I agree. And anyway, the str bug may be unrelated to what you're doing. This patch let's you ignore it. It's easy to debug it separately by adding a str call to your code of you want to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment