"Pythonj Fatal error: UNREF invalid object

[Tim Peters]

[Courageous]
> Regarding the subject line, what semantics causes the above fatal
> error to occur, generally?

Sorry, I've never seen it fail, so the only known cause is "Joe wrote an
extension" <wink>.

[Michael Hudson]
> Looks like[1] it happens when internal gc structures get messed up.

No, it's not a gc thing.  In a debug build (Py_DEBUG), or when Py_TRACE_REFS
is defined (Py_DEBUG implies Py_TRACE_REFS), the layout of Python objects
changes, and *all* dynamically allocated Python objects (even those that
don't participate in gc) are inserted in a doubly-linked list headed at
refchain (a static vrbl in object.c).  In practice this means all objects
except for a handful of static type objects; it does include int objects and
string objects and everything else, and is orthogonal to cyclic gc.

The message in question occurs when it's time to deallocate an object O, but
O doesn't appear to be in the doubly-linked list.  It's hard to speculate
about likely causes, since I really haven't seen it trigger.  Plausible
causes include:

+ Trying to delete an object twice (although I'd expect a memory fault
  then, since deleting it the first time would have set
  op->_ob_next = op->_ob_prev = NULL).

+ Not initializing an extension object correctly -- _Py_NewReference(ob)
  has to get called when an object pops into existence, in order to
  insert ob into refchain.  But PyObject_Init ususally does that for
  you.

If it's random memory corruption, perhaps defining SLOW_UNREF_CHECK will
catch it earlier.