Eric Snow:
> For now I'll revert.  This is not code that changes very often, so there isn't much benefit to keeping it merged.  Testing against a separate branch is just as easy.

Again, Python shutdown is *really* fragile. Last time I tried to "enhance" it, I also introduced random regressions and so I had to revert my changes.

Old info about the crash, should still be relevant:
https://bugs.python.org/issue36114#msg337090

> Could you point me at an immage for that VM or instructions on how to reproduce it?  I hate having to bother you to test my changes! :)

*In theory*, you should be able to reproduce the crash on any platform. But in my experience, bugs which involve multiple threads are simply "more likely" on FreeBSD because FreeBSD manages threads very differently than Linux. Sometimes, a bug can only be reproduce on one specific FreeBSD computer, but once the root issue has been identified, we start to be able to trigger the crash reliably on other platforms (like Linux).

My procedure to reproduce the crash on FreeBSD:
https://bugs.python.org/issue36114#msg337092

I'm using FreeBSD 12.0 RELEASE VM hosted on Linux. My FreeBSD is not customized in any way.

On modern Linux distributions, coredumps are no longer written in the current directory but handled by a system service like ABRT on Fedora. For this reason, Python test runner can "miss" crashes, especially in child processes run by tests (not directly in the process used to run the test).

To get a coredump in the current directory on Linux, you can use:

sudo bash -c 'echo "%e.%p" > /proc/sys/kernel/core_pattern'

Manual test:

$ ./python -c 'import ctypes; ctypes.string_at(0)'
Segmentation fault (core dumped)

vstinner@apu$ git status
...
Untracked files:
	python.18343
...

Say hello to python.18343 coredump!


Usually, running the command which trigger the crash multiple times in parallel (in different terminals, using screen and multiple terminals, etc.) makes the crash more likely since it does stress the system.

Sometimes, I run the Python test suite in parallel to stress the system even more.

The goal of the game is to trigger a race condition which depends on time. Stressing the system helps to "randomize" timings.