Closed jakebott closed 4 years ago
Thanks, @jakebott! Great bug report! Although I wasn't able to reproduce it on my Mac, that docker image allowed me to reproduce it and track it down.
The TL;DR is that it was a bug uptream, and I was able to work around it pretty easily by moving the initialization of the multiprocessing pool until after we've had a chance to load the modules (and crash out).
Here's how I put it in the release notes for Green 3.1.1:
Fix included in Green 3.1.1, just released.
Thanks @CleanCut! I have double-checked and so I can confirm that Green 3.1.1 fixes the problem.
FYI, the way I fixed this in 3.1.1 introduced hangs and crashes (I observed them on macOS)...with increasing chances of problems with each additional subprocess. I fixed the regression in 3.2.0 while preserving this fix. I recommend anyone using 3.1.x upgrade to at least 3.2.0.
I have recently noticed that if a test tries to import a non-existent module, it will print out a stack trace then hang indefinitely instead of the expected behaviour of reporting a failed test or crashing.
Reproducing the error
Create a file called
test_something.py
in an empty directory with the following contents:Run green in the directory. It will produce the following output as expected:
Now uncomment line 2 and re-run green. It will produce the following output then hang indefinitely without returning.
If the process is then terminated by pressing control+C, it will print this:
System Information
OS: Arch Linux (also reproducible on our CI system which uses the python:3.8 docker image CPU: i7-8750H (CI runs on an AMD Ryzen 9 3900X)
Please let me know if there is any other information that would be useful.