- Zope-Dev - Zope lists

Python 2.1.2 does not fix the signal 11 crashing problem !!!!!!!!!!!
by Harald Koschinski 21 Jan '02

21 Jan '02

Hallo, after switching to python 2.1.2 compiled with GC (intranet:/usr/local/src/Python-2.1.2 # ./configure --without-pymalloc) the crashes are back again :-((((((((((((((((((((((( ------------------------------------------------------------------------------------- 2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11 2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11 2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11 2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan 21 09:30:43 2002: Aiieee! 6749 exited with error code: 11 ------------------------------------------------------------------------------------- What is the way to finaly fix the problem???? regards Harald Matthew T. Kromer wrote: > Harald Koschinski wrote: > >> same for me, no more crashes - but zope needs very much memory (logo >> :-(() >> >> I will try know python 2.1.2. >> > > > OK -- our Zope 2.5.0 betas 3 and 4 have a binary python in them that > contains the critical ceval.c patch. > >> > > >

1 0

Re: [Zope-dev] Core dumps - How to find out the bug?
by Anthony Baxter 21 Jan '02

21 Jan '02

>>> =?iso-8859-1?Q?Dario_Lopez-K=E4sten?= wrote > I only have core dumps to work from. I include the stack from latest core > dump. > I am using python 2.1.2 (release), Zope2.4.3 release, RedHat Linux 7.2. > Python is compiled --without-pymalloc Hm. The bug report you sent is pretty much exactly what I'd expect when hitting the Python Compiler stacksize bug. I suspect the problem here is that Zope 2.4.3 provides it's own complete copy of the Compiler, so you're not seeing Jeremy's fixes. Possible solutions: - wait for Zope 2.4.4 - upgrade to the current CVS version of the Zope 2.4 branch, Zope-2_4-branch. This contains what will become (hopefully, shortly) 2.4.4. I'm assuming there's a 2.4.4 planned. - upgrade to the current 2.5 beta. > > ----- > #0 0x0806fb77 in subtract_refs (containers=0x80b228c) at > ./Modules/gcmodule.c:170 > #1 0x0806ff74 in collect (young=0x80b228c, old=0x80b2298) at > ./Modules/gcmodule.c:382 > #2 0x080701c2 in collect_generations () at > ./Modules/gcmodule.c:479 Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Core dumps - How to find out the bug?
by Dario Lopez-Kästen 21 Jan '02

21 Jan '02

Hello! I wonder what to do when zope coredumps? I have been given the advice to hook up gdb to zope/python and see what happens, but there are two problems with this: 1) I barely know gdb at all, let alone know how to hook it up to a running process 2) The dumps happen at random (last one happened at 3 in the morning when a co-worker was working from home). I only have core dumps to work from. I include the stack from latest core dump. I am using python 2.1.2 (release), Zope2.4.3 release, RedHat Linux 7.2. Python is compiled --without-pymalloc What can I do more to track this down? Thanks, /dario ----- #0 0x0806fb77 in subtract_refs (containers=0x80b228c) at ./Modules/gcmodule.c:170 #1 0x0806ff74 in collect (young=0x80b228c, old=0x80b2298) at ./Modules/gcmodule.c:382 #2 0x080701c2 in collect_generations () at ./Modules/gcmodule.c:479 #3 0x08070255 in _PyGC_Insert (op=0x8c1dbbc) at ./Modules/gcmodule.c:508 #4 0x0807eb8e in PyMethod_New (func=0x82fa3dc, self=0x8c1d50c, class=0x82f9f14) at Objects/classobject.c:1834 #5 0x0807c74c in instance_getattr2 (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:642 #6 0x0807c67e in instance_getattr1 (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:608 #7 0x0807c789 in instance_getattr (inst=0x8c1d50c, name=0x8168e00) at Objects/classobject.c:656 #8 0x0808d291 in PyObject_GetAttr (v=0x8c1d50c, name=0x8168e00) at Objects/object.c:1052 #9 0x0809b7ba in builtin_hasattr (self=0x0, args=0x8d8cb94) at Python/bltinmodule.c:886 #10 0x08058df1 in call_cfunction (func=0x80c79c8, arg=0x8d8cb94, kw=0x0) at Python/ceval.c:2850 #11 0x080577ac in eval_code2 (co=0x82d91a0, globals=0x82ebd9c, locals=0x0, args=0x8a3a7e0, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:1952 #12 0x080590a3 in call_eval_code2 (func=0x82f9fb4, arg=0x8a3a7d4, kw=0x0) at Python/ceval.c:2971 #13 0x08058ce4 in call_object (func=0x82f9fb4, arg=0x8a3a7d4, kw=0x0) at Python/ceval.c:2810 #14 0x08058f77 in call_method (func=0x82f9fb4, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2928 #15 0x08058cd1 in call_object (func=0x8b9f2dc, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2808 #16 0x08058bcb in PyEval_CallObjectWithKeywords (func=0x8b9f2dc, arg=0x80cb8fc, kw=0x0) at Python/ceval.c:2745 #17 0x0807c433 in PyInstance_New (klass=0x82f9f14, arg=0x80cb8fc, kw=0x0) at Objects/classobject.c:489 ------ - -------------------------------------------------------------------- Dario Lopez-Kästen Systems Developer Chalmers Univ. of Technology dario(a)ita.chalmers.se ICQ will yield no hits IT Systems & Services

2 1

ExternalFile released
by Craeg K. Strong 21 Jan '02

21 Jan '02

In case any of you hadn't seen it yet, here is the news item I just posted on zope.org: ExternalFile 0.8 Released (Stable) Created by arielpartners <http://www.zope.org/Members/arielpartners> on 2002/01/17. This is the second public release of our ExternalFile <http://www.zope.org/Members/arielpartners/ExternalFile> product. Why not simply use ExtFile <http://www.zope.org/Members/MacGregor/ExtFile>? Because ExternalFile supports pointing to a file "in situ" like a symbolic link, rather than copying it into some central repository directory. This may not seem like a big deal, until you consider that those files might be stored in a revision control system like CVS. ExternalFile gives you the ability to create a Zope object that points to a file in, for example, a CVS sandbox for its content. This new release adds "workalike" capabilities. ExternalFile can now behave like any of the following: * DTMLDocument * DTMLMethod * Image ExternalFile is usable by itself. It is also the base class for CVSFile, to be released shortly. --Craeg

1 0

Re: [Zope-dev] Security Gurus Wanted
by vio 19 Jan '02

19 Jan '02

* vio <vmilitaru(a)sympatico.ca> [020119 09:56]: > vio wrote: > > Just a word to thank you for your reply. > > But incidently, wouldn't it be a good idea for Globals.InitializeClass() > > to throw an error > > or a warning of some kind for hanging 'security.stuff()' declarations, > > declarations which do not have a related ClassSecurityInfo object AT THE > > CLASS LEVEL? > > That would be a fine idea. Unfortunately, there is no straightforward > way telling that you called methods on the security object in the class > definition. Why not simply check for the keyword 'security.' in the class source ? Anything beginning with that word most probably has something to do with security. But if 'security' is not a reference to a security object, just throw an exception. This would make everything so much simpler. > > When you call Globals.InitializeClass(your_class), it looks for a > ClassSecurityInfo object, and doesn't find one. If I understood correctly, this should be treated like an error: not allow the programmer to have calls to security methods which aren't there, because that's more or less what's happening here. And definitely not be silent about it !!! That's a syntax error or something. So Globals.InitializeClass(your_class) finds the declaration 'security.declareSomething()' inside a class, but 'security' being a reference to a ClassSecurityInfo object AT THE MODULE LEVEL somehow has no effect at the class level (while I wrongly thought that by declaring it at the module level like that, it will behave more or less like a 'global' variable). I wonder what was carried at the class level, but something definitely was, else Python would have thrown something ugly at me. In my opinion, Globals.InitializeClass() should check such calls to security methods, and by all means NOT remain silent if it can not carry out the call because it couldn't find a ClassSecurityInfo object's method. Throw a 'method not found' error or something like that. Silence = 'bad'. I'll even say it's a bug. Vio

3 4

Security Gurus Wanted
by vio 19 Jan '02

19 Jan '02

Could someone have a look at the following 'Boring' class with the security functionality added (as described in ZopeBook/6.Security and some other products). Could 'security' machinery be broken in Zope-2.4.1 ? It surely doesn't seem to work as adverised, on my machine at least (Debian Linux 2.2, Zope 2.4.1 (source release) python 2.1.0, linux2). Tell me if it works on your installation. Boring.py -------------------------------- __doc__ = "" __version__ = '0.1' import Globals from Globals import HTMLFile # fakes a method from a DTML file from Globals import MessageDialog # provid from Globals import Persistent # makes an object stick in the ZODB import OFS.SimpleItem import Acquisition import AccessControl.Role from AccessControl import ClassSecurityInfo READ_PERM = 'View Stuff' WRITE_PERM = 'Change Stuff' security = ClassSecurityInfo() manage_addBoringForm = HTMLFile('boringAdd', globals()) def manage_addBoring(self, id, title='', REQUEST=None): """Add a Boring to a folder.""" self._setObject(id, Boring(id, title)) if REQUEST is not None: return self.manage_main(self, REQUEST) class Boring( OFS.SimpleItem.Item, # A simple Principia object. Not Folderish. Persistent, # Make us persistent. Yaah! Acquisition.Implicit, # Uh, whatever. AccessControl.Role.RoleManager # Security manager. ): """Boring object. """ meta_type = 'Boring' # what do people think they're adding? manage_options = ( # what management options are there? {'label': 'Edit', 'action': 'manage_main'}, {'label': 'View', 'action': ''}, # defaults to index_html {'label': 'Security', 'action': 'manage_access'}, ) # NOTE: commented out following as it seem to conflict with # 'security.declareP...()' declarations later on # __ac_permissions__=( # what permissions make sense for us? # ('View management screens', ('manage_tabs','manage_main')), # ('Change permissions', ('manage_access',) ), # ('Change Borings' , ('manage_edit',) ), # ('View Borings', ('',) ), # ) def __init__(self, id, title=''): """initialise a new instance of Boring""" self.id = id self.title = title # SECURITY - ==================================================== # here I played with '#'s, then simply tried to access 'index_html' # after each security declaration, # as user 'Anonymous', and noted the results on same line. # 'NOT-WORKING' simply means not working as advertised (allowed access when # it shouldn't, and vice-versa). As you can see, there are too many # 'NOT-WORKING' results. Do you come to similar results? # My conclusion is that security declarations have no effect whatsoever, # whether I declare something, then its oposite, I end up with the same # result. This shouldn't be. security.setPermissionDefault(READ_PERM, ['Stuff Manager','Manager']) security.setDefaultAccess('deny') # <== NOT-WORKING # security.declarePrivate('index_html') # <== NOT-WORKING # security.declarePublic('index_html') # <== OK # security.declareProtected(READ_PERM, 'index_html') # <== NOT-WORKING index_html = HTMLFile('index', globals()) security.declarePublic('manage_main') # <== NOT-WORKING manage_main = HTMLFile('boringEdit', globals()) def manage_edit(self, title, REQUEST=None): " " self.title = title if REQUEST is not None: return MessageDialog( title = 'Edited', message = "Properties for %s changed." % self.id, action = './manage_main', ) Globals.InitializeClass(Boring) --------------------------------

2 3

Re: [Zope-dev] im_self of methods accessed via non trivial acquisition
by Phillip J. Eby 19 Jan '02

19 Jan '02

At 01:12 PM 1/18/02 +0100, Stefan Bund wrote: >"Phillip J. Eby" <pje(a)telecommunity.com> writes: > > > > Method rebinding is done only when an item is retrieved from the aq_self > > side, and only if im_self points to aq_self. If these conditions are met, > > a new binding is created which points to the acquisition wrapper. > > > > This is a feature, not a bug. If you rebind im_self on the aq_parent side, > > and your method assigns a value to an attribute of self, it will be > > assigned to the wrong object! It is safe in your example to bind m.im_self > > to B, because B.aq_base is f, the true self of m. But it is not safe to > > bind m.im_self to A, because A.aq_base is g -- another object altogether. > > > > I guess another way to look at it is that a method retrieved from an > > acquisition-wrapped object will always meet the condition that > > method.im_self.aq_base is the original object the method was retrieved > > from. This ensures that the method simply works with an > > acquisition-wrapped version of its original self. > >Of course, im_self cannot be A, that would be wrong, but as far as I >understand, it could be a *new* acquisition wrapper, something like /B >o A/ or even /[f] o A/: > >C--A--O--[a] >| | | >| | [b] >| | >| O--B--O--[c] >| | | | >| | | [d] >| | | >| | O--[e] >| | | >| | [f] >| | >| [g] >| >B--O--[c] >| | >| [d] >| >O--[e] >| >[f] > >(that's what I refer to in the definition of /C/). So if /C/ is one of >the aforementioned new wrappers, /C.aq_base/ is indeed [f] and >therefore, /C/ would be safe as im_self? > >Hmm. Is there another reasun, why method rebinding works the way it >does (returning a subtree and not a new acquisitionwrapper like >described above) or am I completely amiss? Beats me. I guess nobody's asked for the feature, and in any event it requires global knowledge of the tree structure that would be very difficult to code. The current behavior is a rule that is applied locally at each acquisition wrapper, and the wrappers don't know what wrapper is pointing to them, so it's really not practical for them to try and do something that "smart". It may also be that what you're asking for is a bad idea, in which case Jim Fulton can probably explain why. :)

1 0

Folding Zope Into an Install
by Noah Friedland 18 Jan '02

18 Jan '02

Fellow Zopers: I have recently completed a small app built on zope. I am trying to build an inno setup install script that will install zope silently (with a pre-determined master user/password). Any help on this would be greatly appreciated. --N

1 0

Re: [Zope] Error on install
by Eron Lloyd 18 Jan '02

18 Jan '02

Chris (or anybody else), Have you tried to install Beta4 using the linux binary package yet? I'm trying to write a patch against it but the installation does in fact bomb out each time I try to run it, even freshly untarred. The source TGZ works fine and dandy, however. It seems compilezpy.py has been dramatically changed since Beta3, as if to try and surpress the stdout messages. I'm going to try and break it down and find out where the exceptions are flagging, and also refactor my patch so it doesn't depend on the changes being made to compilezpy.py. I don't like wrapping a gag around code if I don't have to, and I'd rather this stuff be written to an install log or something. I-see-a-fishbowl-proposal-for-a-new-installer-ly yours, Eron On Thursday 17 January 2002 12:23 pm, you wrote: > Sure, go ahead! > > ----- Original Message ----- > From: "Eron Lloyd" <lloyd(a)lancaster.lib.pa.us> > To: <zope(a)zope.org> > Sent: Thursday, January 17, 2002 12:00 PM > Subject: Re: [Zope] Error on install > > > Ah hah! Yet another one...if no one objects, I'd like to try and patch > > compilezpy.py to ignore the test directory during install. I'll submit > > this > > > to the Collector when done. > > > > Eron > > > > On Thursday 17 January 2002 11:28 am, you wrote: > > > I am installing Zope and I get the bellow errors. > > > Could someone explain why I'm getting this? > > > > > > Thanks > > > > > > Allen May > > > MCSi Web Admin > > > 800.842.1702 x7628 > > > > > > > > > > > > Compiling python modules > > > File "/usr/zope/Zope-2.4.3-linux2-x86/lib/python2.1/test/nocaret.py", > > > line 2 > > > [x for x in x] = x > > > SyntaxError: can't assign to list comprehension > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future3.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future4.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future5.py, line 4) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future6.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future7.py, line 3) > > > > ------------------------------------------------------------------------- > >- > > - > > > >- > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev )

3 3

im_self of methods accessed via non trivial acquisition
by Stefan Bund 18 Jan '02

18 Jan '02

I have already posted this question on the main zope list but have not received a reply. I hope som Acquisition god is following this list to shed some light on this matter. If there is some kind of definite documentation for the acquisition machinery especially for how methods are fetched across acquisition, I would appreciate a pointer to that Documentation. I allready tried to digest the ZDG (chapter on Acquisition) and the information on the 'AcquisitionMadness' page <http://www.zope.org//Wikis/zope-dev/AcquisitionMadness>. Is there any more *definite* information on Acquisition apart from the source code. The problem is, I have a bit difficulty reading the source since it's an extension class :-(... But now on to the details of my original question (this is a copy of my post to the zope list): My question regards the details of how the contents of im_self of an acquired method is calculated by the acquisition machinery. To illustrate this, I will depict an acquisition tree using the following symbols: O -- an acquisition wrapper <upcase letter> -- an acquitsition wrapper named for further reference [<lowercase letter>] -- an object -- -- the aq_parent link | -- the aq_self link I will use the following acquisition tree for illustration (it resembles the tree I have in my application, I just reduced it to make my point) A--O--[a] | | | [b] | O--B--O--[c] | | | | | [d] | | | O--[e] | | | [f] | [g] (Note: some of the a-g's are identical, but for simpler reference from the text, i have named them all differently ...) In this representation, the acquisition order is from bottom to top. The bottom most object is /A.aq_base/. Acquisition along containment only produces horizontal lines of acquisition wrappers. let /m/ be a method of the objekt /f/. The expression of interest is x := A.m I would expect /x.im_self/ to be an acquisition wrapper C C := A.f where (as far as i understand the rules of acquisition) /C.aq_parent == A/ But instead displaying /x.im_self/ yields the acquisition tree rooted at /B/ !! I find this a bit disturbing. My question: 'Is it a *bug* or a *feature*?'. I hope, I made my point clear. I hope someone can shed light on this subject, Stefan.

2 1