Dieter Maurer wrote:
(gdb) info threads 6 Thread 40965 (LWP 29363) 0x080d1e77 in visit_decref (op=0x503c1b54, data=0x0) at Modules/gcmodule.c:225 5 Thread 32772 (LWP 29362) 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 4 Thread 24579 (LWP 29361) 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 3 Thread 16386 (LWP 29360) 0x42028d69 in sigsuspend () from /lib/i686/libc.so.6 2 Thread 16385 (LWP 29358) 0x420d224b in poll () from /lib/i686/libc.so.6 1 Thread 8192 (LWP 29312) 0x420d3b2e in select () from /lib/i686/libc.so.6
We do not see enough to determine the cause of the spinning.
When the situation above remains (i.e. Thread 6 is running while all others are sleeping) when you let your program run (and later stop) again, then this would indicate an infinite loop in the cyclic garbage collector. We would then need a closer look why this happens.
I see. Thanks, Dieter. As I've had more time to look into this problem, it is apparent that Zope is *not* spining forever. It is just taking several minutes to recover from the first access to instances of the refreshed product. Repeating the "info threads" gives the same results for the several minutes that Zope is unresponsive. So I feel like I am doing something in my Product that is causing the garbage collector a whole lot of trouble when the Product is refreshed. Are there any guidelines for "stupid things you should never do in a Product"? TIA, JZ