asterite added the comment: 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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30260> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
