Message299516
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']) |
|
Date |
User |
Action |
Args |
2017-07-30 19:39:53 | thehesiod | set | recipients:
+ thehesiod, methane, yselivanov |
2017-07-30 19:39:53 | thehesiod | set | messageid: <1501443593.14.0.552521899649.issue31061@psf.upfronthosting.co.za> |
2017-07-30 19:39:53 | thehesiod | link | issue31061 messages |
2017-07-30 19:39:53 | thehesiod | create | |
|