Opened 3 years ago

Last modified 23 months ago

#32557 new New feature

Fail tests when unraisable exceptions occur

Reported by: Adam Johnson Owned by: nobody
Component: Testing framework Version: dev
Severity: Normal Keywords:
Cc: Carlton Gibson, Tom Forbes, Chris Jerdonek Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Following django-developers discussion:

Django's test runner should install an unraisable exception hook and fail the test run if it is ever triggered. The check could be done just once at the end of the test run (in subprocesses when run in parallel), because unraisable exceptions already print their traceback by default.

Change History (6)

comment:1 by Adam Johnson, 3 years ago

There's a reference implementation in pytest we might be able to copy:

Additionally here's an implementation I've used - calling the context manager in an overridden DiscoverRunner.run_tests to wrap the whole test run:

def fail_if_any_unraisable_exceptions():
    orig_unraisable_hook = sys.unraisablehook
    hook_called = multiprocessing.Value("b", lock=False)
    hook_called.value = 0

    def hook(unraisable, /):
        hook_called.value = 1

    sys.unraisablehook = hook

        sys.unraisablehook = orig_unraisable_hook

        if hook_called.value:
                "❌ Unraisable exceptions reported, failing test run - see above.",

comment:2 by Mariusz Felisiak, 3 years ago

Cc: Carlton Gibson Tom Forbes added
Triage Stage: UnreviewedAccepted

Tentatively accepted. I would like to check this in practice.

comment:3 by Mariusz Felisiak, 3 years ago

Cc: Chris Jerdonek added

comment:4 by Chris Jerdonek, 3 years ago

One comment: the sys.unraisablehook() docs say:

Called when an exception has occurred but there is no way for Python to handle it. For example, when a destructor raises an exception or during garbage collection (gc.collect()).

Thus, with this patch, if we disable garbage collection as in this PR:
then it seems like we won't get the benefit of this patch in checking for exceptions that occur during garbage collection.

Last edited 3 years ago by Chris Jerdonek (previous) (diff)

comment:5 by Adam Johnson, 3 years ago

Exceptions in __del__ are only one kind of unraisable exception. The other kind I know of that motivated me to look into them are from async tasks that were not joined by the task that spawned them.

Python already prints tracebacks for unraisable exceptions, the main point of this ticket is to ensure that such tracebacks in tests do not get missed because the tests exit with a 0 status code. The default behaviour looks like this:

$ cat
class Naughty:
    def __del__(self):
        1 / 0


$ python
Exception ignored in: <function Naughty.__del__ at 0x1015da8b0>
Traceback (most recent call last):
  File "/Users/chainz/tmp/test/", line 3, in __del__
    1 / 0
ZeroDivisionError: division by zero

$ echo $?

The PR disabling gc affects only objects in cycles, which are a minority. Moreover all garbage is still collected at interpreter shutdown, so any unraisable exceptions would have their traceback printed at that point, although they indeed not be picked up by a sys.unraisablehook installed only for the duration of the test run. That said, the gc PR affects only the Django test suite which has no unraisable exceptions at the moment, and it's likely if any were added someone would spot them.

comment:6 by Thomas Grainger, 23 months ago

You should be able to run gc.collect in a loop until no more objects get collected just before you unset your unraisablehook

Or just a constant number of gc.collect cycles 4 should be enough for anyone

Last edited 23 months ago by Thomas Grainger (previous) (diff)
Note: See TracTickets for help on using tickets.
Back to Top