1

Resolved

Exception thrown by SafeRepr

description

When a Python object represents natively-allocated memory which has since been freed, accessing it can cause crashes.

I don't suppose there's a lot that PyTools can do about that, but Blender does offer a special "python safety" build flag which causes invalid access attempts to give a Python exception instead of a crash. Trouble is, the Python debugger doesn't handle the exception: instead it throws it and messes up the debug session.

I've fixed this locally by changing SafeRepr.__call__ to include a try/except block:
    def __call__(self, obj):
        try:
            return ''.join(self._repr(obj, 0))
        except Exception as e:
            return "{}: {}".format(type(e).__name__,str(e))
I'm sure there are other places where the same fix is needed, but at least now I can break into my code without having to track down obscure hanging pointers. :-)

comments

Zooba wrote Jan 20 at 5:30 PM

Thanks for this. I've added a fix along these lines for our next release.

What I actually wrote was:
    def __call__(self, obj):
        try:
            return ''.join(self._repr(obj, 0))
        except:
            try:
                return 'An exception was raised: %r' % sys.exc_info()[1]
            except:
                return 'An exception was raised'
The differences are basically to support a wider range of Python versions (we still officially support CPython 2.5) and also to better handle out-of-memory errors or strange exception types. (If you look in PythonScraper.py you'll see all sorts of exception handling for things that should never throw - some extension modules do very strange things... Blender is very well behaved by comparison!)