Fatal Python error: GC object already in linked list

[Tim Peters]

[Jimmy Retzlaff]
> I'm working on an application in Python and my application occasionally
> dies with the error:
>
> Fatal Python error: GC object already in linked list
>
> I'm quite unfamiliar with Python's implementation, but I tried studying
> a little in this case. That error message only appears in a macro in
> objimpl.h (_PyObject_GC_TRACK), and that macro only seems to be used in
> a function that creates traceback objects in traceback.c
> (newtracebackobject).

You need to get a better string-searching program <wink>.  For example, you
missed this key use in gcmodule.c:

void
PyObject_GC_Track(void *op)
{
	_PyObject_GC_TRACK(op);
}

If you possibly can, build a debug-mode Python from source, and run under a
debugger.  The message is produced by a call to Py_FatalError(), and on
Windows that in turn calls the Win32 DebugBreak() function.

> ...
> Looking at CVS it appears the use of that macro was added to prevent
> the old memory leak that could happen when calling sys.exc_info().

All objects of all container types that can appear in reference cycles
eventually invoke _PyObject_GC_TRACK.  This is what lets cycle garbage
collection know that such objects need to be watched.  You get the error
message if you try to tell gc to pay attention to an object it's already
paying attention to.  IOW, somebody is calling _PyObject_GC_TRACK on a given
object twice.  In a debugger you'll see exactly who's doing it, and on which
object.

> My program is a non-trivial (~15K lines of Python) GUI app on Windows
> based on wxPython. I've been developing this app for 6-8 months and the
> error just started showing up about 3 weeks ago. I haven't updated any
> major components (other than my own code) for a few months, so I'm
> guessing my own code changes have triggered this.

If you don't have any C code of your own in this mix, you're probably
tickling a memory-management bug in wxPython (or some other C extension).
Such problems are unlikely to be in the core Python code, but that's not
impossible either.

> Occurrences seem quite random, which can indicate timing issues of
> course.

Try

import gc
gc.disable()

at the start.  If the problem goes away then, it doesn't prove anything, but
at least it would be amusing <wink>.

> Windows XP Pro (I've also seen the problem on Windows 2000)
> Python 2.2 (the standard Windows binary distribution)

Move to Python 2.2.1 ASAP, please.  That did fix one excruciatingly rare and
subtle bug in the interaction between cyclic gc and a delicate gimmick that
lets you deallocate multi-hundred deep nested containers without blowing
your stack space.

> Win32all Build 146
> wxPython 2.3.2.1 Hybrid (also seen it with a Normal build)
> Numeric 20.3

Ouch.