[issue31061] asyncio segfault when using threadpool and "_asyncio" native module
Alexander Mohr
report at bugs.python.org
Sun Jul 30 15:39:53 EDT 2017
Alexander Mohr added the comment:
this is the comment on the assert:
/* Python's cyclic gc should never see an incoming refcount
* of 0: if something decref'ed to 0, it should have been
* deallocated immediately at that time.
* Possible cause (if the assert triggers): a tp_dealloc
* routine left a gc-aware object tracked during its teardown
* phase, and did something-- or allowed something to happen --
* that called back into Python. gc can trigger then, and may
* see the still-tracked dying object. Before this assert
* was added, such mistakes went on to allow gc to try to
* delete the object again. In a debug build, that caused
* a mysterious segfault, when _Py_ForgetReference tried
* to remove the object from the doubly-linked list of all
* objects a second time. In a release build, an actual
* double deallocation occurred, which leads to corruption
* of the allocator's internal bookkeeping pointers. That's
* so serious that maybe this should be a release-build
* check instead of an assert?
*/
I've also attached a file that's similar to the code we run in production, however couldn't get it to reproduce the crash. In the datafile it uses it has some tuples like the following:
StationTuple = namedtuple('StationTuple', ['stationname', 'stationsubtype', 's2id'])
----------
Added file: http://bugs.python.org/file47050/python_crash.py
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue31061>
_______________________________________
More information about the Python-bugs-list
mailing list