- Zope-Dev - Zope lists

DocumentTemplate/tests/testDTML.py fails with Python2.2
by Ken Causey 29 Mar '02

29 Mar '02

I'm trying to make use of the DocumentTemplate classes for Zope CVS (checked out yesterday afternoon) in a project in which I would really like to use Python2.2 (I do have reasons). I'm finding however that the unit tests fail with Python2.2 even though they succeed with Python2.1. For example DocumentTemplate/tests/testDTML.py fails 13 of the 18 tests. I'm wondering if this is a known issue and if anyone can point me in the right direction to fix this. Thanks, Ken Causey P.S. I'm not subscribed to this list, so please be sure to reply directly to me as well as the list, as appropriate.

2 2

ZEO storage server zdaemon question??
by Eric Roby 29 Mar '02

29 Mar '02

I am starting a ZEO storage server. Looking at start.py, unless I specify -s option (resets the z variable) the zdaemon runs by default (if I start it as root). However, when I start it I only see two "nobody" processes (running on a Linux box). In previous ZServer configurations, when started as root, I saw the zdaemon (root) process and then the "nobody" processe(s). Am I mis-understanding or am I doing something stupid??? Eric

1 0

Bad Marshal Data
by seb bacon 28 Mar '02

28 Mar '02

I've asked this before, about a year ago, but got no response. Does anyone else ever see 'bad marshal data' errors sometimes? What are they a symptom of? It sometimes happens in my products, other times in Zope. It always occurs on import statements. I usually manage to fix it by playing around with line spacing, etc, in the module being imported. Deleting *pyc files does not help. Here's an example: Traceback (most recent call last): File "/usr/local/Zope-2.5.1b1-src/lib/python/OFS/Application.py", line 531, in import_product product=__import__(pname, global_dict, global_dict, silly) ValueError: bad marshal data seb

3 2

re: [Zope-dev] Crashing problem? Python workaround?!
by Martijn Jacobs 27 Mar '02

27 Mar '02

Hi Matt, Leo.... > Pythonlabs found this today after much assistance from the folks on > #zope on the irc.openprojects.net system; particularly, Leonardo Rochael > Almeida's assistance has been extremely valuable in isolating this > problem. And jus to say it again : thank you all again!! You've made a customer very happy again! > This is an intermediate workaround until Pythonlabs develops an official > fix. However, by using this workaround, you do not need the specially > modified ZServerPublisher module I coded. Will this patch be included in the next Zope binary releases? I could build a zope for on a particular environment, but it would be alot easier to upgrade all customers with the new binary release. Anyway : In other words : if this is added in the official Python release, the bug is cleanly resolved? -- martijn jacobs east site

1 0

Crashing problem? Python workaround?!
by Matthew T. Kromer 27 Mar '02

27 Mar '02

Hey fellow Zopistas: If you're still experiencing crashing problems with Python 2.1.2, and Zope, please consider trying the following test: From a clean Python build tree, modify Include/object.h line 587. #define PyTrash_UNWIND_LEVEL 50 make this read #define PyTrash_UNWIND_LEVEL 5000000 Rebuild Python, and Zope, with the new patched Python. Test it. If this makes your problem go away, please post here to the list. Technical details: this patch prevents Python from storing objects in an internal "trashcan" of objects which need to be deleted, but aren't -- a way to avoid C stack recursion. The trashcan code is not safe from the normal garbage collector; it steals a few fields in the object that the GC depends on (the reference count and the object type field, in fact) and so items in the trashcan will cause the garbage collector to crash with a segmentation fault. Objects only go into the trashcan when a recursive delete is detected, with a depth defined by PyTrash_UNWIND_LEVEL. Bumping this number up to a large number has the effect of disabling the trashcan module, at the expense of the C stack (because all of those recursive deletes CAN happen then.) Pythonlabs found this today after much assistance from the folks on #zope on the irc.openprojects.net system; particularly, Leonardo Rochael Almeida's assistance has been extremely valuable in isolating this problem. This is an intermediate workaround until Pythonlabs develops an official fix. However, by using this workaround, you do not need the specially modified ZServerPublisher module I coded. -- Matt Kromer Zope Corporation http://www.zope.com/

1 0

ZClass Constructor Cleanup for 2.6
by Casey Duncan 27 Mar '02

27 Mar '02

I don't think this is a big enough change to warrant a real proposal, so I'll shoot this out here: Does anyone see a problem with changing the default generated constructor method for ZClasses to a python script in Zope 2.6? I think we are encouraging really bad style by keeping this in DTML, since it is purely business logic. Thoughts? I will, of course, implement this if nobody objects. -Casey

3 4

[Fwd: [Zope-dev] Re: more on the segfault saga]
by Martijn Jacobs 27 Mar '02

27 Mar '02

> Hello segfaulters and others interested in Zope instability issues! Hello again :) > Our demi-god Matt Kromer from ZopeCorp has come up with a possible way > to corner the instability issue AND give you a stable, cycle-garbage > collecting Zope. We probably should build a statue for this guy somedays.... > Since the problem seems, so far, to be caused by the Python Restricted > Compiler (which is used in everything from dtml expressions to python > scripts to other stuff) not completing fully collectable objects > before the Python cycle garbage collector finds them, the solution > is to lock > out the gc while creating these objects. The only easy way to do this > currently is to disable the automatic gc and run manual garbage > collections only when we're pretty sure no one else is running, and at > the same time not letting anyone else run when we're running the gc. Just to make sure : I put gc.disable() in Z2.py and apply this ZServerPublisher.py patch? Or do I have to add some more code to let the garbage collector collect more often or less or... > We're close guys, very close. You can't imagine how glad I would be if this thing is fixed..... Thanks again for all your efforts! Martijn Jacobs East Site

3 3

Re: more on the segfault saga
by Martijn Jacobs 26 Mar '02

26 Mar '02

Hello, We also have the problem with zope crashing with segfault 11..... I've read al earlier posts on this subject, but couldn't notice anything that could arrange a direct solution, or I should have missed something? The only thing I can try is to describe our situation : - We have a production server running zope 2.5.1 beta (binary release, linux), so the crash cannot be from the bugs listed in Matthews Stability Howto. - The crash occurs as well on Windows as on Linux, (both binary releases 2.5 beta 1, as well 2.5.0 as well 2.4.3 on both platforms) - It happens only with "alot" of traffic ("alot" is more then 40 kbytes/sec, 500 users on a intranet, I hope I don't have to scale zope with this little amount of traffic?) - It DOESN't crash with the -t 1 option, so the crash has something to do with threading. However, the performance is very poor with this option, so this is not a good solution. - We use a flash generator c extension module (ming), but with this removed, it still crashes, so it's not a non-standard-zope c extension module that can cause the crash. - We DON't use any DA for relational access, so all earlier suggestions that the mysql/oracle DA modules are causing the crashes should be reconsidered.... - ZOPE_SECURITY_POLICY=PYTHON is not taking away the crashes. - We use our own python Products which are accessed when the crash occures, but these products are very clean and totally written in Python, so that should not be any problem I suppose, because Zope doesn't crash in single thread mode. We also use alot of Python Scripts, but these bugs are already fixed? (says the Stability Howto) I don't know where to start, because attaching GDB doesn't make any sense, since you have to start zope single threaded (according to Matts Stability Howto) and then no crashes occur. Is this problem solved if I install python 2.2 for example? Are there any bugfixes in this release from Python 2.1.2 ? I don't know what the status is right now? Is zope corp. working on it trying to find the bug? Can I be of any help tracking down this bug? regards, Martijn Jacobs East Site mart(a)eastsite.nl

3 9

how to import .zexp containing obsolete products???
by Gilles 26 Mar '02

26 Mar '02

Hello I would like to import very old exported zope file (.bbe or .zexp). ( Note: I know how to convert the zodb2 to zodb3...) Unfortunately theses file contains products which are not installed anymore now: old db adaptor,confera... and the import failed. This is not really nice. Is there a way to do the import anyway? not importing the unknown or broken objects?? Or to 'clean' the old .bbe/.zexp from thoses objects? Thanks Gilles

1 0

from ImageFile import ImageFile
by John Ziniti 26 Mar '02

26 Mar '02

__The short story__: I would like to recommend to all Product developers that for Product initialization, they please the statement: from App.ImageFile import ImageFile instead of: from ImageFile import ImageFile __The long story__: A colleague of mine recently went through much trouble, which eventually boiled down to a name- clash with piddle/PIL. Zope imports the name ImageFile into it's global namespace during startup. A lot of Products take advantage of this during Product initialization, by importing the name using: "form ImageFile import ImageFile" The Zope source, though, states explicitly that "this module will disappear in the future". At the very least, the following Products have trouble (and I suspect many more, as well): TinyTablePlus MetaPublisher LDAPAdapter ZDconfera ZSyncer ZOracleDA NISUserFolder Thanks, Ziniti

1 0