Dieter,
I tried the whole gdb threads debugging thing, with the following (nil)
results. Any other ideas? A lot of the instructions online seem to be
Linux-centric, so I'm at a loss as how to proceed:
(gdb) info threads
* 7 LWP 100099 0x2820e544 in pthread_mutexattr_init () from
/usr/lib/libpthread.so.2
6 Thread 0x8111000 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
5 Thread 0xa358400 (LWP 100098) 0x2821546b in pthread_testcancel ()
from /usr/lib/libpthread.so.2
4 Thread 0x9918200 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
3 Thread 0x9064400 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
2 Thread 0x9064e00 (runnable) 0x0807b36f in PyType_IsSubtype ()
1 Thread 0x9a32200 (runnable) 0x08b53622 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0x9064e00 (runnable))]#0 0x0807b36f in
PyType_IsSubtype ()
(gdb) call PyRun_SimpleString("import sys, traceback;
sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()")
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x9a32200 (LWP 100099)]
0x08b53622 in ?? ()
The program being debugged was signaled while in a function called from
GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (malloc) will be
abandoned.
(gdb) call PyRun_SimpleString("import sys, traceback;
sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()")
Cannot set lwp 100099 registers: Invalid argument
Cannot set lwp 100099 registers: Invalid argument
--
jsoffron: I'm generally pretty high on national defense...
Mr. Bad Example: Careful...it's a gateway policy. Before you know it,
you'll be mainlining the hard stuff like trade agreements.
jsoffron: Too late...I've been freebasing Nafta all day... Sweet,
sweet NAFTA.
- As seen on Slashdot
> -----Original Message-----
> From: Dieter Maurer [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 16, 2006 2:36 PM
> To: Matthew X. Economou
> Cc: zope@zope.org
> Subject: Re: [Zope] DeadlockDebugger revisited
>
> Matthew X. Economou wrote at 2006-6-16 09:10 -0400:
> >I thought a recent operating system upgrade (FreeBSD 5.4 to 6.1)
> fixed
> >my problems with Zope. Unfortunately, once I re-compiled Python et
> al
> >(to remove dependencies on the old libraries), my problems with
> Zope
> >deadlocking recurred. I tried to use a combination of tools to try
> to
> >discover the root cause of this problem, but nothing seems to work.
> >What am I missing, and what else can I try?
>
> Your description seems to match an error case, I have seen
> under Python 2.3.4 with Linux 2.4 kernel:
>
> When a SIGSEGV occurs, then Zope's main thread (the ZServer
> thread) dies
> (and Zope therefore stops responding) but the other threads
> remain alive and keep all sockets open.
>
> The primary culprit was Python, although the Linux thread
> implementation
> had to help to expose the bug in this way.
>
>
> I had thought that the problem were fixed in Python 2.3.5 (which you
> use). Thus, maybe, your problem is different from the one
> outlined above. Use OS means to check in what state the various
> Zope threads are and whether the primary thread still exists.
>
>
> If this is not the problem cause, you can attach your
> Zope process with "gdb" and analyse the state -- especially
> that of the main thread. There is a howto around how to do that.
>
>
> --
> Dieter
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
