July 2002 - Zope-Dev

Re: [Zope-dev] Confusing segfault for Zope2 head on RH7.3
by Dieter Maurer 18 Jul '02

18 Jul '02

Barry A. Warsaw writes: > .... > At the PyErr_SetString() call > PyExc_IndexError is a perfectly valid PyObject*, but just one stack > frame later, inside the PyErr_SetString, the exception object is a > completely bogus address. PyErr_SetString() is not getting the same > object that Splitter_item() is providing in the first argument. Note > that the second argument, a char* is just fine. This looks like a compiler error, maybe an error in the dynamic linking code. I would single step through the assembler code and check whether the parameter is pushed onto the stack, whether this stack address is overwritten during the call sequence (which may include dynamic linking code) and whether the variable is referenced in "PyErr_SetString" from the correct frame offset. To do this, you would use "display/i $pc" and then single step on assembly level "xi" until you are beyond the setup code of "PyErr_SetString". You should find the frame offsets of you parameters with "i addr <parameter>". When you like, you can send me the output for further examination. Dieter

2 1

add new base classes dynamically with hotfixes
by Yuppie 18 Jul '02

18 Jul '02

Hi! I want to modify existing Zope classes without touching the code of the product packages. This how-to seems to fit exactly my needs: http://www.zope.org/Members/Caseman/Dynamic_Hotfix But one thing I don't know how to do: > 1. Add new base classes to existing classes, such as CatalogAware (use > the __bases__ attribute). It works with (classic) Classes, as described here: http://www.linuxjournal.com/article.php?sid=4540 But Zope uses also ExtensionClasses. The __bases__ attribute of ExtensionClasses appears to be read-only and ExtensionClass is a run-out model (see http://mail.python.org/pipermail/python-dev/2001-December/018807.html ). So what I'm looking for, is a work-around. Any ideas? Thanks! Yuppie

1 0

Zope+java applet
by Juliette Colmant 18 Jul '02

18 Jul '02

Hi, I wanted to know if it was possible to call a java applet with Zope? What kind of object do I have to use? When shall I put the file of my java Applet? Does someone have a little example? Thanks, Juliette. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Leak in 2.5.1 cAccessControl.c !?
by Stefan H. Holek 18 Jul '02

18 Jul '02

Hi All! I believe I have found a leak in cAccessControl.c of Zope 2.5.1. See the patch below. It was difficult to spot because in the respective section of cAccessControl.c the 'owner' variable is reused several times. Note that 'ASSIGN' decrefs 'owner' before actually assigning, whereas the original line doesn't and thus leaks a ref (I think). I was hunting for leaked ImplicitAcquirerWrappers and was able to track them down to Owned.getOwner() which returns wrapped User objects (LeakFinder rocks!). The patch appears to stop the wrappers from leaking. However, I am still leaking Users so I am not sure whether I have really and completely nailed it. From what I have seen in Acquisition.c decref'ing a wrapper also decrefs the wrappee. Assuming that no special handling of wrapped vs. unwrapped objects is required (with regards to decref'ing) what I observe may well be unrelated. What do you think? If somebody can confirm this I will put it in the Collector. Thanks, Stefan --- cAccessControl.c Fri Apr 12 17:18:44 2002 +++ cAccessControl.c Thu Jul 18 13:22:48 2002 @@ -1028,7 +1028,7 @@ } if (owner != Py_None) { - owner = PyObject_GetAttr(owner, allowed_str); + ASSIGN(owner, PyObject_GetAttr(owner, allowed_str)); if (owner) ASSIGN(owner, callfunction2(owner, value, roles)); if (owner == NULL) -- Those who write software only for pay should go hurt some other field. /Erik Naggum/

1 0

Zope 2.4.3 & patched Python 2.1.3 @ FreeBSD crashing
by Myroslav Opyr 17 Jul '02

17 Jul '02

Hi, In past times I was advised to apply a patch and increase stack size for pthreads of FreeBSD. I did and it helped for Zope 2.5.0 & CMF 1.2 + PageTemplates. It was moderately stable situation but it appears to crash again. For other site (with other Zope version)... Zope Version (Zope 2.4.3 (source release, python 2.1, linux2), python 2.1.3, freebsd4) Python Version 2.1.3 (#4, May 15 2002, 17:31:48) [GCC 2.95.3 20010315 (release) [FreeBSD]] System Platform freebsd4 If portions (PT) of a web-page are rendered everything is ok. Management screens either has no problems. But rendering a compound PT-based page makes Zope crash with assertion "STACK_LEVEL() <= f->f_stacksize" failed: file "Python/ceval.c", line 695 on console. What is suggested solution? Increase pthreads stacksize? it was THREAD_STACK_SIZE=0x20000 as advised... Thanks, m. -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav(a)zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578

2 2

Segregation of the Zope2 and Zope3 checkins implemented
by Ken Manheimer 17 Jul '02

17 Jul '02

I've just committed the change to the file that dictates checkin notice routing so that Zope3 checkins are directed to the zope3-checkins(a)zope.org mailling list, instead of being included in the zope-checkins(a)zope.org list. For those of you on the latter list interested in continuing to get zope3 checkins, subscribe to the zope3-checkins list at: http://lists.zope.org/mailman/listinfo/zope3-checkins Happy hacking! -- Ken klm(a)zope.com

1 0

Restricted Compiler issues on FreeBSD? (Core Dumps...waaa!)
by Jeffrey P Shell 17 Jul '02

17 Jul '02

For a while now, Tracker has been core dumping on my with Zope 2.5.1 with both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel). The culprit seems to be expressions that are heavy on parenthesis. For example, the following works:  But it core dumps when changed to:  Don't ask me what this expression does - I just kept whittling at it until the crashes stopped. Then I went and found quite a few others. I made a lot of fixes by turning complex expressions into many smaller ones inside a single 'let' tag. Does anyone know other possible fixes for this issue? Is there some Python stack size setting I can set at compile time? I have some other code that has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD. FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was compiled by hand. -- Jeffrey P Shell www.cuemedia.com

4 3

Singleton DA possible?
by Brad Clements 17 Jul '02

17 Jul '02

The gvibDA interbase adapter really must have exactly one database connection shared among all threads. Even though the DA is derived from THUNKED_TM, there are still multiple instances of the DA created, one for each thread (depending on server load). What I really want is "one DA" that is controlled through a thread-lock for all threads. I realize I may need to create a proxy object.. any suggestions on how best to design this? -- Also, even running Zope with -t 1, I still sometimes get 2 DA objects. I can even see that the __del__ method on the earlier DA instance is being called. But that still messes it up. Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements

1 0

Confusing segfault for Zope2 head on RH7.3
by barry＠zope.com 17 Jul '02

17 Jul '02

Working on the Zope 2.7 branch I noticed a very strange crash while running the test suite. I re-checked out the Zope 2 cvs head, rebuilt everything from scratch and I still get the crash. I'm about out of ideas so I thought I'd post what I know here in case anyone else can confirm or give clues. First off, I'm using a fresh checkout of the Zope 2 cvs head with a virgin Python 2.1.3 (although a cvs head of the Python 2.1 maintenance branch has the same problem). I've rebuilt Python 2.1.3 with only the -g option (no -O, although it makes no difference), and I've rebuilt Zope using this command: % python2.1 setup.py build_ext -i which also builds with just the -g option, although that also makes no difference. Note that I've also built using "python2.1 wo_pcgi.py" and that also makes no difference. I then run the test suite like so: % PYTHONPATH=lib/python python2.1 utilities/testrunner -a and I reliably get a crash in ISO_8859_1_Splitter.c I've boiled it down to the following simplified test case: -------------------- snip snip --------------------crash.py from Products.PluginIndexes.TextIndex.Splitter.ISO_8859_1_Splitter.ISO_8859_1_Splitter import ISO_8859_1_Splitter x = ISO_8859_1_Splitter('hello world') list(x) -------------------- snip snip -------------------- run it like so: % PYTHONPATH=lib/python python2.1 crash.py The top of the backtrace is: #0 PyErr_SetString (exception=0x6e727574, string=0x402660dc "Splitter index out of range") at Python/errors.c:69 #1 0x402658af in ISO_Splitter_item (self=0x843ed98, i=2) at Products/PluginIndexes/TextIndex/Splitter/ISO_8859_1_Splitter/src/ISO_8859_1_Splitter.c:357 #2 0x0808b98d in PySequence_List (v=0x843ed98) at Objects/abstract.c:1258 #3 0x080b934f in builtin_list (self=0x0, args=0x810137c) at Python/bltinmodule.c:1357 ... (I hacked the C code to rename Splitter_item() in ISO_8859_1_Splitter.c to ISO_Splitter_item() for ease of setting the break point.) Here's the deal. Splitter_item() cruises along as expected until it hits the end of the text. word is Py_None and it drops into the clause that sets the IndexError exception. AFAICT, there are no reference counting bugs in the code. At the PyErr_SetString() call PyExc_IndexError is a perfectly valid PyObject*, but just one stack frame later, inside the PyErr_SetString, the exception object is a completely bogus address. PyErr_SetString() is not getting the same object that Splitter_item() is providing in the first argument. Note that the second argument, a char* is just fine. Stepping through the code with gdb gives no help. I can set break points and inspect all the objects created and decref'd and everything appears okay. Printing PyExc_IndexError right before the call shows nothing strange, but stepping into PyErr_SetString() shows the first arg is corrupted. I don't get it. I've show the other PLabbers and it perplexes them too. :) To make matters weirder, we've tested this on various Linux flavors and versions. On RH6.1 and MD8.{0,1} it works just fine -- no crash. The /only/ system that I've seen the crash is RedHat 7.3, and there it crashes on both of my up-to-date RH7.3 systems, every time, and reliably. I think I've eliminated gcc as a culprit because most of our Linux boxes are using the same gcc version, according to gcc -v: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) i.e 2.96 20000731. The /only/ difference that I can tell is the glibc version. My RH7.3 systems have glibc 2.2.5 and on all the other systems glibc's are older; no system with glibc 2.2.4 or earlier exhibits the crash. I have not tested gcc 3.1 and I have not tried other glibc's on RH7.3. I'd really like to know if anybody else on RH7.3 either sees the same crash or doesn't. And if so <wink> what version of gcc and glibc you've got. I'm starting to suspect a glibc bug, but it's dang strange. -Barry

1 0

Adding Items to Object Manager and Folders
by Ross Boylan 17 Jul '02

17 Jul '02

The Zope Developer's Guide and the API docs (Zope 2.5) present different stories about how to add things to object managers. I don't really follow what the API stuff is doing. This is a request for clarification. Devguide says do def addFunction(dispatcher, id): "Create object and add to self" p = SomeProduct(id) dispatcher.Destination()._setObject(id, p) This makes sense, though, as commented at http://www.zope.org//Members/michel/Projects/Interfaces/ObjectManager, it relies on a private, undocumented method. addFunction is in outer scope of a module, and is hooked up wtih various calls in ___init__.py. On the other hand, the ObjectManager API says to do self.manage_addProduct['OFSP'].manage_addFolder(id, title). First, what scope should that be done in? Second, this seems to create one product (OFSP) and then add a folder to it, so that it creates two, nested products. The API for Folder mentions manage_addFolder as a constructor, but again the scope is unclear to me. Presumably it needs to know what to add it to, but that is not passed in. Finally, the use of id in two places in the first code snippet (one apparently associated with the container, the other with the object) seems like an invitation to trouble. Why is it done that way? One reason I want to know this is that I'm considering having a container that would automatically label (or set id) of its contents (e.g., 'a' is first, 'b' is second....). Thanks for any light you can shed.

2 1