fatal error: GC object already tracked

[Tim Peters]

[Vikram]
> i have a program which uses multiple threads and downloads pages using
> pycurl and processes these pages among other things. the program works
> fine with python 2.2 and pycurl 7.10.8 ;
>
> with python 2.3 i get two kinds of errors maybe related? a)  python
> dumps core and prints out "Fatal Python error: GC object already
> tracked"

That error check is new in 2.3, but a program trying to track a GC object
that's already been tracked has always been breaking the rules.  Because
that's a very low-level problem with C code, you may or may not see an
immediate problem as a consequence of breaking the rules.  A segfault is one
possible bad consequece; arbitrary memory corruption is another; no obvious
problem at all is a third.  Luck of the draw.

I'm not familiar with pycurl, but if any of it is written in C, the root
cause  is almost certainly that pycurl is using the Python C API
incorrectly.

> b) the program just waits at update_refs() function inside
> the python GC code path and doesn't append anything to the logs nor
> perform any activity.

update_refs() is a very simple function, and the only way I can see for it
to get stuck is if somebody is mucking with Python objects in another thread
while cyclic gc is running.  The other thread would be in error then, as the
global interpreter lock is always held by the thread running cyclic gc when
cyclic gc is running, and it's strictly forbidden (but, alas, impossible to
*enforce* at the C level) for any thread to do anything with Python objects
when it doesn't hold the GIL.  This symptom is one that's never been
reported before, but is consistent with the theory that pycurl is using the
Python C API incorrectly.

> any idea why or suggestions ?
>
> 			Vikram
>
> ps: the Fatal Python error: GC object already tracked" error seems to
> be an open bug filed by someone else in october 2003.

I figure you mean this:

    http://www.python.org/sf/816476

Since that was also reported against pycurl, nothing else like it has ever
been reported, and there's been no followup from the OP in 3 months, I just
closed that as "presumed 3rd party".  Your best bet is to take it up with
the pycurl folks, since the evidence points at pycurl.