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

Merged
merged 1 commit into from Apr 12, 2012

Conversation

Projects
None yet
3 participants
Contributor

pvaret commented Apr 12, 2012

Hi,

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.

Owner

inducer commented Apr 12, 2012

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

Collaborator

asmeurer commented Apr 12, 2012

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/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/sw/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/Users/aaronmeurer/Documents/pudb/pudb/run.py", line 36, in <module>
    main()
  File "/Users/aaronmeurer/Documents/pudb/pudb/run.py", line 30, in main
    steal_output=options.steal_output)
  File "/Users/aaronmeurer/Documents/pudb/pudb/__init__.py", line 67, in runscript
    dbg.interaction(None, sys.exc_info())
  File "/Users/aaronmeurer/Documents/pudb/pudb/debugger.py", line 206, in interaction
    self.set_frame_index(index)
  File "/Users/aaronmeurer/Documents/pudb/pudb/debugger.py", line 157, in set_frame_index
    self.ui.update_var_view()
  File "/Users/aaronmeurer/Documents/pudb/pudb/debugger.py", line 1433, in update_var_view
    locals, globals)
  File "/Users/aaronmeurer/Documents/pudb/pudb/var_view.py", line 461, in make_var_view
    tmv_walker.walk_value("", var, locals[var])
  File "/Users/aaronmeurer/Documents/pudb/pudb/var_view.py", line 257, in walk_value
    displayed_value = get_stringifier(iinfo)(value)
  File "/Users/aaronmeurer/Documents/pudb/pudb/var_view.py", line 235, in <lambda>
    str(custom_stringifier_dict["pudb_stringifier"](value)))
  File "/Users/aaronmeurer/Documents/pudb/example-stringifier.py", line 81, in pudb_stringifier
    return run_with_timeout("str(obj)", 0.5, {'obj':obj})
  File "/Users/aaronmeurer/Documents/pudb/example-stringifier.py", 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/example-stringifier.py error !!).

@inducer inducer added a commit that referenced this pull request Apr 12, 2012

@inducer inducer Merge pull request #36 from pvaret/master
Don't crash PuDB when viewing an object with a buggy str() or repr().
8c6fe86

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

Owner

inducer commented Apr 12, 2012

Sounds good. Thanks, both of you!

Collaborator

asmeurer commented Apr 12, 2012

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.

Owner

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...

Contributor

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
that?

Owner

inducer commented Apr 13, 2012

Meh, too much effort. :)

Collaborator

asmeurer commented Apr 13, 2012

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