RE: [Zope] DeadlockDebugger revisited
This time, when it locked, I thought to try a backtrace.
(gdb) info threads
* 7 LWP 100098 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 0xa1e1a00 (LWP 100047) 0x2821546b in pthread_testcancel ()
from /usr/lib/libpthread.so.2
4 Thread 0x8c91e00 (runnable) 0x08098bc0 in _PyEval_SliceIndex ()
3 Thread 0x8c92c00 (runnable) 0x081008e0 in PyModule_Type ()
2 Thread 0x9061e00 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
1 Thread 0x991ac00 (sleeping) 0x2820df0f in pthread_mutexattr_init ()
from /usr/lib/libpthread.so.2
(gdb) thread 2
[Switching to thread 2 (Thread 0x9061e00 (sleeping))]#0 0x2820df0f in
pthread_mutexattr_init () from /usr/lib/libpthread.so.2
(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 0x8c91e00 (LWP 100098)]
0x08098bc0 in _PyEval_SliceIndex ()
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) bt
#0 0x08098bc0 in _PyEval_SliceIndex ()
#1 0x0809ba98 in _PyEval_SliceIndex ()
#2 0x0809c420 in PyEval_EvalCodeEx ()
#3 0x080cd2d2 in PyFunction_SetClosure ()
#4 0x0805973c in PyObject_Call ()
#5 0x0805f192 in PyMethod_New ()
#6 0x0805973c in PyObject_Call ()
#7 0x28465dbd in load_binpersid () from
/usr/local/lib/python2.3/lib-dynload/cPickle.so
#8 0x28466eea in load () from
/usr/local/lib/python2.3/lib-dynload/cPickle.so
#9 0x0809b310 in _PyEval_SliceIndex ()
#10 0x0809ba98 in _PyEval_SliceIndex ()
#11 0x0809ba98 in _PyEval_SliceIndex ()
#12 0x0809ba98 in _PyEval_SliceIndex ()
#13 0x0809c420 in PyEval_EvalCodeEx ()
#14 0x080cd2d2 in PyFunction_SetClosure ()
#15 0x0805973c in PyObject_Call ()
#16 0x0805f192 in PyMethod_New ()
#17 0x0805973c in PyObject_Call ()
#18 0x08059911 in PyObject_CallMethod ()
#19 0x28498671 in unghostify () from
/usr/local/www/Zope28/lib/python/persistent/cPersistence.so
#20 0x28499aff in Per_setstate () from
/usr/local/www/Zope28/lib/python/persistent/cPersistence.so
#21 0x28524a21 in P_getattr () from
/usr/local/www/Zope28/lib/python/Persistence/_Persistence.so
#22 0x284d1c29 in Wrapper_findattr () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#23 0x284d2367 in Wrapper_getattro () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#24 0x08091372 in _PyUnicodeUCS4_IsAlpha ()
#25 0x0809b310 in _PyEval_SliceIndex ()
#26 0x0809c420 in PyEval_EvalCodeEx ()
#27 0x080cd2d2 in PyFunction_SetClosure ()
#28 0x0805973c in PyObject_Call ()
#29 0x08096de7 in PyEval_CallObjectWithKeywords ()
#30 0x0805971b in PyObject_CallObject ()
#31 0x284cb59a in callfunction4 () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#32 0x284cbc85 in ZopeSecurityPolicy_validate () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#33 0x0805973c in PyObject_Call ()
#34 0x08096de7 in PyEval_CallObjectWithKeywords ()
#35 0x080ca342 in PyComplex_AsCComplex ()
#36 0x0805973c in PyObject_Call ()
#37 0x0805f192 in PyMethod_New ()
#38 0x0805973c in PyObject_Call ()
#39 0x08096de7 in PyEval_CallObjectWithKeywords ()
#40 0x0805971b in PyObject_CallObject ()
#41 0x284cb62d in callfunction5 () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#42 0x284cc6f9 in SecurityManager_validate () from
/usr/local/www/Zope28/lib/python/AccessControl/cAccessControl.so
#43 0x0809b310 in _PyEval_SliceIndex ()
#44 0x0809c420 in PyEval_EvalCodeEx ()
#45 0x0809a7ab in _PyEval_SliceIndex ()
#46 0x0809c420 in PyEval_EvalCodeEx ()
#47 0x0809a7ab in _PyEval_SliceIndex ()
#48 0x0809c420 in PyEval_EvalCodeEx ()
#49 0x0809a7ab in _PyEval_SliceIndex ()
#50 0x0809c420 in PyEval_EvalCodeEx ()
#51 0x080cd2d2 in PyFunction_SetClosure ()
#52 0x0805973c in PyObject_Call ()
#53 0x0809a3be in _PyEval_SliceIndex ()
#54 0x0809ba98 in _PyEval_SliceIndex ()
#55 0x0809c420 in PyEval_EvalCodeEx ()
#56 0x0809a7ab in _PyEval_SliceIndex ()
#57 0x0809c420 in PyEval_EvalCodeEx ()
#58 0x080cd2d2 in PyFunction_SetClosure ()
#59 0x0805973c in PyObject_Call ()
#60 0x0805f192 in PyMethod_New ()
#61 0x0805973c in PyObject_Call ()
#62 0x0809a3be in _PyEval_SliceIndex ()
---Type to continue, or q to quit---
#63 0x0809c420 in PyEval_EvalCodeEx ()
#64 0x080cd2d2 in PyFunction_SetClosure ()
#65 0x0805973c in PyObject_Call ()
#66 0x0805f192 in PyMethod_New ()
#67 0x0805973c in PyObject_Call ()
#68 0x08096de7 in PyEval_CallObjectWithKeywords ()
#69 0x284d14e6 in CallMethodO () from
/usr/local/www/Zope28/lib/python/Acquisition/_Acquisition.so
#70 0x0805973c in PyObject_Call ()
#71 0x08098b36 in _PyEval_SliceIndex ()
#72 0x0809c420
RE: [Zope] DeadlockDebugger revisited
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 )
Re: [Zope] When is an empty list not an empty list?
Aloha, Thanks, I understand...though it's a bit annoying that it looks and acts just like a list but "isn't"... Just using "items" does work. I figured it would work for True when not empty...I wasn't so sure what it would return when empty, as sometimes the test seems to be on 'exists' rather than 'empty', depending on the type of object. At least I grok this particular case now, thanks again... cheers, John S. Tino Wildenhain wrote: John Schinnerer wrote: Aloha, I have a python script, getCatalogItems(), which returns a (possibly empty) list resulting from a catalog query. The lone parameter is the sort index; the rest of the query is taken from the request. Anyhow... If nothing was found, I don't want to display an empty table of results. When I do this query and then check for empty list to see if the query returned any items: ... ...it doesn not work, that is, the (empty) table displays when items is in fact an empty list. If I do this instead: ... ...then the condition works, no empty table is displayed if the list is empty. Why does the former not work and the latter does? I need to understand the difference in the python expressions...makes no sense to me at present that they don't work the same. Well, thats because getCatalogItens() does not return a list. It might look and work like it, but it isnt the same class. Python defines comparisions between different classes as always false. Easier in your case would be just: tal:condition="items" non empty python objects are usually logically True. Regards Tino ___ 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 ) -- John Schinnerer - MA, Whole Systems Design -- - Eco-Living - Whole Systems Design Services People - Place - Learning - Integration [EMAIL PROTECTED] http://eco-living.net ___ 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 )
Re: [Zope] When is an empty list not an empty list?
John Schinnerer wrote: > Aloha, > > I have a python script, getCatalogItems(), which returns a (possibly > empty) list resulting from a catalog query. The lone parameter is the > sort index; the rest of the query is taken from the request. Anyhow... > If nothing was found, I don't want to display an empty table of results. > > When I do this query and then check for empty list to see if the query > returned any items: > > > > ... > > ...it doesn not work, that is, the (empty) table displays when items is > in fact an empty list. > > If I do this instead: > > > > ... > > ...then the condition works, no empty table is displayed if the list is > empty. > > Why does the former not work and the latter does? > I need to understand the difference in the python expressions...makes no > sense to me at present that they don't work the same. > Well, thats because getCatalogItens() does not return a list. It might look and work like it, but it isnt the same class. Python defines comparisions between different classes as always false. Easier in your case would be just: tal:condition="items" non empty python objects are usually logically True. Regards Tino ___ 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 )
[Zope] questions on multilingual sites
Aloha, I'm currently doing a custom small business site that might also want to be in French further down the road. I've never used the internationalization aspects of zope yet...so a few basic questions: Can additional language support be added in later, or is it necessary to build it all in from the start (even if not used yet)? What are the basic docs/tutorials/howtos I should look at to start understanding how zope language support works and how to best apply/use it? thanks for any assistance, John S. -- John Schinnerer - MA, Whole Systems Design -- - Eco-Living - Whole Systems Design Services People - Place - Learning - Integration [EMAIL PROTECTED] http://eco-living.net ___ 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 )
[Zope] When is an empty list not an empty list?
Aloha, I have a python script, getCatalogItems(), which returns a (possibly empty) list resulting from a catalog query. The lone parameter is the sort index; the rest of the query is taken from the request. Anyhow... If nothing was found, I don't want to display an empty table of results. When I do this query and then check for empty list to see if the query returned any items: ... ...it doesn not work, that is, the (empty) table displays when items is in fact an empty list. If I do this instead: ... ...then the condition works, no empty table is displayed if the list is empty. Why does the former not work and the latter does? I need to understand the difference in the python expressions...makes no sense to me at present that they don't work the same. thanks for any help, John S. -- John Schinnerer - MA, Whole Systems Design -- - Eco-Living - Whole Systems Design Services People - Place - Learning - Integration [EMAIL PROTECTED] http://eco-living.net ___ 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 )
