"Tim Peters" <tim at zope.com> writes: > [Michael Hudson] >> ... >> One way of getting _Py_RefTotal out of sync is resurrecting objects in >> __del__ methods. > > Oops! That's right: [snip evidence] This is also why running test_descr in a loop still bumps sys.gettotalrefcount() by 3 or so each time. > /* If Py_REF_DEBUG, the original decref dropped _Py_RefTotal, > * but _Py_NewReference bumped it again, so that's a wash. > > Heh. If you ignore the new reference(s) that resurrected the thing, I > suppose that would be true. It should (2.3.2) do > > _Py_DEC_REFTOTAL; > > to make up for the extra increment done by _Py_NewReference; likewise in > slot_tp_del (BTW, the macro expands to nothing if Py_REF_DEBUG isn't > defined). Is it that easy? I remember fooling a little with this, but not successfully. It's just possible <wink> that I got confused, though. (Confused by finalizer issues? How could that be?) FWIW, my foolings were with new-style objects -- but from what you say in another post, it's unsurprising to find isomorphic problems with old-style classes (as in your example). Cheers, mwh -- Java is a WORA language! (Write Once, Run Away) -- James Vandenberg (on progstone at egroups.com) & quoted by David Rush on comp.lang.scheme
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4