[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

David Butler added the comment: resolved as wont fix, because its not python's fault :) -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Amaury Forgeot d'Arc 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 modify this DynamicSl

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 0xb76619

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 already tracked... " Someon

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 0xb75a02b0

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Jesús Cea Avión 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 have to do a f

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Jesús Cea Avión 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 this situatio

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 type?

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Jesús Cea Avión 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" object?. I

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 (generation=2) a

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Jesús Cea Avión 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 pointed out, if you

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

Amaury Forgeot d'Arc 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 that most of the t

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

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 objects *