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 () at
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Hey, you found it!
PySide::DynamicSlotDataV2::callback() calls PyMethod_New() without getting the
GIL. The Python allocator is not thread-safe, operations are supposed to be
serialized by this Global Interpreter Lock.
I suggest to
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
Jesús Cea Avión j...@jcea.es added the comment:
It seems to be a real infinite loop. Bad thing. Could be a bug in an extension,
difficult to say.
This is going to be VERY difficult to debug without a reproductible case we can
try.
Could you possibly check the object type of the infinite loop
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 to
Jesús Cea Avión j...@jcea.es added the comment:
Instrumentalize: check for this pathological case (an object with a GC pointer
back to itself) in the code that modify the GC pointers. Lets say, everytime
code change the pointers, you test for this. Luckily you can learn the codepath
creating
Jesús Cea Avión j...@jcea.es added the comment:
David, if you get desperate, let us know. If you can deal with Mercurial and
compiling Python code, I could post a mercurial repository/branch with code
modifications to help you to debug this.
But it is almost Christmas and I am VERY busy and
Jesús Cea Avión j...@jcea.es added the comment:
The only way of this thing actually happening is if the GC link list has
actually a cycle.
Without a testcase to try to reproduce, it can't be debugged.
David, can you reproduce this consistently, even if it takes a few hours?.
As Amaury
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
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Are you sure that the program is really stuck in the gc module?
The loop you mention has to go through all objects of the process. It's
possible that it allocated many objects, that one garbage collection takes a
few seconds, and even
13 matches
Mail list logo
