[Zope-Coders] Zope 2.5 instability problems

[Martijn Faassen]

Hi again,

Some more info on this, running Zope from gdb to see where it crashes.
Unfortunately I suspect that the C traceback isn't too useful, as I
suspect the corruption happens earlier somewhere, triggering the crash
later..

Here's the top of one gdb 'bt':

#0  0x400505bc in PyTuple_New () from /usr/lib/libpython2.1.so.0.0
#1  0x40050bfd in PyTuple_SetItem () from /usr/lib/libpython2.1.so.0.0
#2  0x40033b5d in PySequence_GetSlice () from /usr/lib/libpython2.1.so.0.0
#3  0x4005cc8b in _PyBuiltin_Init () from /usr/lib/libpython2.1.so.0.0
#4  0x40062c88 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.1.so.0.0
#5  0x40062b63 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.1.so.0.0
#6  0x40062e43 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.1.so.0.0
#7  0x40062b30 in PyEval_CallObjectWithKeywords ()
   from /usr/lib/libpython2.1.so.0.0
#8  0x400629e3 in PyEval_CallObjectWithKeywords ()

This occurs when I open a node in the DOM tree view of ParsedXML, and
hen try to open another one; frequently I get a crash then..

But, opening a node and then going to the management interface
elsewhere can get a crash as well:

0  0x4036f15a in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:389
#1  0x4036f2ea in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:433
#2  0x4036f2ea in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:433
#3  0x4036f2ea in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:433
#4  0x4036f2ea in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:433
#5  0x4036f2ea in Wrapper_findattr (self=0x8973818, oname=0x8049b70, 
    filter=0x0, extra=0x0, orig=0x0, sob=1, sco=1, explicit=0, containment=0)
    at ././../Components/ExtensionClass/src/Acquisition.c:433

in a completely different place, so it's pretty clear the corruption happens
earlier..  Since I get no crashes if I run the unit tests (or generate
XML output) against ParsedXML and the main difference there is that I go
around the security infrastructure, I suspect that this may be the 
culprit.

I don't think that this is a ParsedXML problem; ParsedXML just apparently
causes the symptoms to reveal itself (lots of use of computed attribute?
lots of wrapperobject creation?). And I need help with this.

Help!

Regards,

Martijn