I made up a small program to reproduce an issue, it consists of two files, test.py and test2.py, the second one is imported as a module by the first one, so they should be but in the same dir.

# ls
test.py  test2.py
# python3.5 test.py 
test
Segmentation fault

The files contain a rather weird combination of references to objects put in other objects or to modules of standard lib. This is what I got after reducing the code to reproduce the problem. All those references are probably needed to make a cycle and to postpone it's deallocation until the interpreter shutdown.

Regarding where in the real world such a code exists: it was spread by a combination of modules, namely tornado (https://github.com/tornadoweb/tornado), pyzmq (https://github.com/zeromq/pyzmq) and circus (https://github.com/circus-tent/circus), I found the problem when running one of the tests of circus:

~/circus# python3.5 -m nose -v circus.tests.test_reloadconfig:TestConfig.test_reload_ignorearbiterwatchers
test_reload_ignorearbiterwatchers (circus.tests.test_reloadconfig.TestConfig) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.037s

OK
Segmentation fault

Also, sometimes that test fails like this:
# python3.5 -m nose -v circus.tests.test_reloadconfig:TestConfig.test_reload_ignorearbiterwatchers
test_reload_ignorearbiterwatchers (circus.tests.test_reloadconfig.TestConfig) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.021s

OK
Fatal Python error: GC object already tracked

Current thread 0x00007f20aa7b6700 (most recent call first):
Aborted