100% CPU and RAM when handling exception raised from itself

[tomage]

Hi!

First of all: Thanks for a great library! Rollbar, and pyrollbar, has been a very useful tool for me in my work.

I recently tackled very pernicious problem at work. We had a situation where our servers would in rare occasions start hogging CPU at 100% and slowly run out of RAM.

This happened when we raised an exception from itself. Something that probably isn't very usual, or even correct, but it did happen by accident in a medium-big Django/Django Rest Framework codebase, where exception handlers got some wires crossed.

To illustrate, here's a crude view of the situation:

def my_view(request):
    # do stuff
    raise Foo()

def request_dispatch(request):
    try:
        self.run_view(request)  # original exception raised here
    except Exception as exc:
        self.handle_exception(exc)

def handle_exception(self, exc):
        new_exc = wrap_exception(exc)  # In rare situations, this would return exc straight up
        raise new_exc from exc

Of course, one could argue that raising an exception from itself is a terribly bad idea - and probably it is!

But the main problem is that the __cause__ attribute of exceptions allows for code to potentially traverse an infinite graph if there is a circular dependency in there.

This caused our servers to go down in production once, and caused us to spend a lot of time debugging.

The reason: Pyrollbar was unraveling the trace-chain, by following exc.__cause__. But since exc.__cause__ == exc, it would unravel forever, hogging CPU, and eating up RAM.

So, I implemented a fix here: #317. It might not necessarily be the right/best way to fix it, but figured to put in a PR anyway.

Interestingly, Django has a similar problem, when DEBUG = True. And I just noticed that recently they patched it (see https://code.djangoproject.com/ticket/29393 and https://github.com/django/django/blob/400ec5125ec32e3b18d267bbb4f3aab09d741ce4/django/views/debug.py#L401).