[Zope-Coders] Zope 2.5 instability problems

Chris McDonough chrism@zope.com
Mon, 10 Dec 2001 12:57:24 -0500


Martijn,

Can you try running with Python AccessControl functions in place of
the C versions?  You can do this by following the instructions in the
following modules in the AccessControl package: SecurityManager.py,
DTML.py, PermissionRole.py, ZopeGuards.py, and ZopeSecurityPolicy.py.
If you can run ok on the Python-based access control, we'll need to
investigate the C access control module.

As an aside, that seems like a lot of places that you need to disable
C-based access control.  Sigh.

----- Original Message -----
From: "Martijn Faassen" <faassen@vet.uu.nl>
To: <zope-coders@zope.org>
Sent: Monday, December 10, 2001 12:31 PM
Subject: Re: [Zope-Coders] Zope 2.5 instability problems


> 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
>
>
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://lists.zope.org/mailman/listinfo/zope-coders
>