David Butler croe...@gmail.com 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
David Butler croe...@gmail.com 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 already
David Butler croe...@gmail.com 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
David Butler croe...@gmail.com added the comment:
resolved as wont fix, because its not python's fault :)
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13616
David Butler croe...@gmail.com 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=optimized out) at
Modules/gcmodule.c
David Butler croe...@gmail.com added the comment:
2011/12/19 Jesús Cea Avión rep...@bugs.python.org
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
New submission from David Butler croe...@gmail.com:
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
