New submission from David Butler :
CPU will sit a 100% indefinitely, this is also pretty tough (takes several
hours) to reproduce
if you step through the program it is stuck between 290 and 292
Modules/gcmodule.c:
/* Set all gc_refs = ob_refcnt. After this, gc_refs is > 0 for all obje
David Butler added the comment:
sorry for the delay, I had to wait until the problem occurred again...
I gdb'ed into the process again, the backtrace is a little different this
time...
(gdb) bt
#0 0xb76adfc6 in update_refs (containers=) at
Modules/gcmodule.c:292
#1 collect (generat
David Butler added the comment:
2011/12/19 Jesús Cea Avión
I am willing to work toward a simplified test case, but its going to be
difficult, I am hoping that I can narrow down the source of the problem...
Forgive me, I'm gdb is actually a new thing to me... how could I check the
object
David Butler added the comment:
I have 10 identical test machines running this this code ( operating systems
are cloned ). I am not usning valgrind in these tests, it was causing various
issues...
(gdb) info sharedlibrary
>FromTo Syms Read Shared Object Library
0xb75a0
David Butler added the comment:
This also looks familiar:
http://bytes.com/topic/python/answers/36901-fatal-error-gc-object-already-tracked
"semi-randomly locks somewhere outside my C-code (after returning to
python), and semi-randomly issues a "Fatal error: GC object alrea
David Butler added the comment:
I think I have found the problem! I took a closer look at the Fatal error core:
#0 0xb76fe424 in __kernel_vsyscall ()
#1 0xb740ccb1 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb740e3f2 in *__GI_abort () at abort.c:92
#3
David Butler added the comment:
resolved as wont fix, because its not python's fault :)
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.
