[Zope-Coders] Zope 2.5 beta 4

[Matthew T. Kromer]

On Monday, January 14, 2002, at 01:29 PM, Martijn Faassen wrote:
>>
>
> Did you make any progress on the ParsedXML issues (crashes when using 
> the
> new C based security, no crashes when I say ZOPE_SECURITY_POLICY = 
> PYTHON)?
> Can you still not reproduce it? I'd like to get this one nailed as I
> really have no clue how ParsedXML could be causing this, it happens
> on various versions of Linux (Red Hat, Debian), it happens with various
> versions of Python 2.1 (hand compiled, debian's, CVS version, etc), and
> it only ever goes away once I say ZOPE_SECURITY_POLICY=PYTHON.
>

I have not been able to produce  a crash; however I was easily able to 
get Zope to spin to death, regardless of what ZOPE_SECURITY_POLICY is 
set to.  The __getattr__ of ParsedXML is my primary culprit; I suspect 
it has some very bad behavior when there is complex structure.  The 
difference of enabling or not the C access control I think has to do 
with running out of stack space, but without being able to reproduce 
this...

When I instrumented the __getattr__ function in ParsedXML I saw a ton of 
references to im_self -- this is what the security policy is doing to 
check to see if it is trying to control access to a method or not.  
However, I'm not familiar enough with ParsedXML to know what to tweak to 
try to do things like cache negative references.  When I threw the 
profiler at it, 50% of the time was spent spinning in that getattr 
inside ParsedXML.

> I could use some assistance on this. :) And it seems very likely to me
> that this is pointing at a real crashbug in the new Zope security
> module..
>
>
While it is possible that there is some actual bad code in the security 
routines, I think what is happening instead is just very very bad 
acquisition behavior which causes a very deeply nested stack and 
ultimately a crash.  This may or not be due to some nuance of the C code 
being exactly the same as the python implementation.