bpo-32374: Enhance test_importlib.test_bad_traverse()#7147
bpo-32374: Enhance test_importlib.test_bad_traverse()#7147vstinner wants to merge 1 commit intopython:masterfrom vstinner:importlib_bad_traverse
Conversation
Make test_bad_traverse() fails if the script raises a Python exception: generic exit code 1. The test expects a crash which means an exit code different than 0 and 1.
|
I'm not 100% sure sure that the test is portable. Maybe on Windows or on other platforms, the exit code is 1 on a crash? But I'm optimistic :-) |
|
AFAIK, C's |
I wasn't sure neither, so I looked at existing tests. If a process is killed by a signal like SIGSEGV or SIGBUS, subprocess.Popen.returncode is a negative number. subprocess.py: We have many tests for that. For example, test_subprocess.test_run_abort() calls os.abort() and then checks self.assertEqual(-p.returncode, signal.SIGABRT). On Windows, the exit code is usually a big number. The test just passed on AppVeyor. So my PR expects that spec.loader.create_module() kills the process with any signal. |
Even if all supported platforms pass, I'm not too comfortable relying on that. It would make porting to new platforms harder. |
|
The code calls spec.loader.create_module(spec) which does crash on Py_VISIT(m_state->integer) because m_state == NULL. test_faulthandler has an unit test on dereferencing a NULL pointer: test_faulthandler_read_null() which checks that the test is killed by a signal, SIGSEGV, SIGBUS or SIGILL. I would say that the signal number is not portable: it depends on the platform. But test_faulthandler pass on all platforms supported by Python.
Oh, I'm not sure that my change is the best option. It's just a proposal :-) |
|
I think it's reasonable for faulthandler to be a bit platform-specific, so a new platform might have to change/disable faulthandler tests (or faulthandler itself). |
4 participants
Make test_bad_traverse() fails if the script raises a Python
exception: generic exit code 1. The test expects a crash which means
an exit code different than 0 and 1.
https://bugs.python.org/issue32374