[Zope-dev] How makesetup deals with Zope ?
Hi, Next week I've tried to install the ParsedXML, under my Zope. Unfortunately, the installation failed. After some hours of hard worker, I've only change the permission of the makesetup file with : chmod 644 /usr/local/zope/Zope-2.4.3-linux2-x86/lib/python2.1/config/makesetup So, I have 2 questions about it 1-- Even I thought to see what makesetup is doing for and what it is doing, is there anybody to explain me in more details, for my personal knowledge ? 2-- In fact, the real question of this mail. The makesetup file should'nt installed with the "x" bit on, when we installed Zope ? Sincerily PS -- Oreka ! Nous sommes l'internet moins cher ! Surfez 25% moins cher avec http://www.oreka.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] recipe for trapping SIGSEGV and SIGILL signals on solaris
Hi Joe, The problem you're seeing is that the fault is happening on a different thread than the receiver of the signal; that truss syntax is interesting though (I have an old SPARC around to test on but its painfully slow) so I'm wondering if first you needed to do an 'info thread' in gdb and then a 'thread N' to switch to the real crashing thread before getting the backtrace. - Original Message - From: "Joseph Wayne Norton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 2:20 AM Subject: [Zope-dev] recipe for trapping SIGSEGV and SIGILL signals on solaris > > Hello. > > We are facing zope restarts on the solaris 5.6 platform with zope > 2.4.3 and python 2.1.1. I put together a script based some > information on an old posting to the apache mailing list. The > following shell/perl script allows one to get a core file from a dying > zope child process and also allow the zope to restart without any side > effects. > > > The script > > #!/bin/sh > PATH=$PATH:/usr/local/bin > export PATH > cd /tmp > for PID in `ps -u zfs -f -o pid,comm,args | fgrep z2.py | cut -d' ' -f1` > do > export PID > truss -f -l -t\!all -S SIGSEGV,SIGILL -p $PID 2>&1 \ > | perl -pe 'system("gcore $ENV{'PID'} && sleep 5 && kill -9 $ENV{'PID'}"), exit($ENV{'PID'}) if /(SIGSEGV|SIGILL)/;' & > done > > > Step 1: modify script to match your environment. > > Step 2: execute script > > Step 3: wait for core file to be dumped in /tmp. > > Step 4: analyze with gdb where $PID is the pid of the dumped process > > #bash gdb /path/to/bin/python /tmp/core.$PID > > #0 0xef5b9810 in _lwp_sema_wait () > (gdb) where > #0 0xef5b9810 in _lwp_sema_wait () > #1 0xef647ea0 in _park () > #2 0xef647b84 in _swtch () > #3 0xef6468a4 in cond_wait () > #4 0xef6467c8 in _ti_pthread_cond_wait () > #5 0x50220 in PyThread_acquire_lock (lock=0xd9d878, waitflag=1) > at Python/thread_pthread.h:313 > #6 0x51f18 in lock_PyThread_acquire_lock (self=0xda39b8, args=0x0) > at ./Modules/threadmodule.c:67 > #7 0x35db4 in fast_cfunction (func=0xda39b8, pp_stack=0xed40f828, > na=0) > at Python/ceval.c:2994 > #8 0x33ca0 in eval_code2 (co=0x267848, globals=0x51ec4, locals=0x0, > args=0x0, > argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) > at Python/ceval.c:1951 > > : > : > > > It seems that we are facing trouble due to the thread library on > solaris (unless the truss command has introduced a side-effect). > > Anyone else facing similiar troubles? or maybe I should post > this to a python mailing list. > > - joe > > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] more than one user: zope 'hangs'
Hello, We have got a funny problem in Zope: if user A issues a long-running query user B also has to wait in the meantime - zope just waits for A's query to finish. We are using interbase as our database and GV Interbase Database Adapter 0.9.6 on a linux system. In the README it says 'threadsafety ... is set to 1 - threads may share the module but not connections' Somehow i suspect the problem lies there. Can anyone give me a hint on this problem? Thanks in advance, Stephan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more than one user: zope 'hangs'
Stephan, This likely means that the interbase database adapter essentially serializes access to the database. You may want to try sending a mail to the DA maintainer if he is not on the list... Thanks! - C - Original Message - From: "Stephan Herschel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 9:30 AM Subject: [Zope-dev] more than one user: zope 'hangs' > Hello, > > We have got a funny problem in Zope: if user A issues a long-running > query user B also has to wait in the meantime - zope just waits for A's > query to finish. > > We are using interbase as our database and GV Interbase Database Adapter > 0.9.6 on a linux system. In the README it says 'threadsafety ... is set > to 1 - threads may share the module but not connections' > > Somehow i suspect the problem lies there. Can anyone give me a hint on > this problem? > > Thanks in advance, > Stephan > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: EINTR ... was Re: [Zope-dev] browser closing connection
> "MTK" == Matthew T Kromer <[EMAIL PROTECTED]> writes: MTK> For what its worth, I tracked this down in the sources and MTK> confirmed that in Zope 2.3, we shipped a modified asyncore.py MTK> with Medusa that handled EINTR, but in Zope 2.4 we used stock MTK> Python's asyncore which does NOT handle EINTR being returned MTK> from select(). IMHO, the distributed Python 2.1 asyncore MTK> behavior is incorrect. This is fixed in Python 2.2. A brief excerpt demonstrates the approach: def poll (timeout=0.0, map=None): if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append (fd) if obj.writable(): w.append (fd) try: r,w,e = select.select (r,w,e, timeout) except select.error, err: if err[0] != EINTR: raise In particular, I didn't use a "while 1:". I believe an operator could send a signal to a process using asyncore and expect it to cause the app to fall out of a poll() call immediately, instead of waiting for the timeout to occur. (It might never occur.) I expect that the interrupted system call will be fairly uncommon, so it shouldn't matter than the poll() is returning without doing any work. In most cases, it will be called from loop() which already has a while loop. A similar fix was made in poll3(), which uses the select module's poll(2) interface. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: EINTR ... was Re: [Zope-dev] browser closing connection
So, which is the "official" way of fixing Zope 2.4.3? wait for a hotfix? apply Matthew's patch? steal asyncore from Python 2.2? On Tue, 2001-12-11 at 12:52, Jeremy Hylton wrote: > > "MTK" == Matthew T Kromer <[EMAIL PROTECTED]> writes: > > MTK> For what its worth, I tracked this down in the sources and > MTK> confirmed that in Zope 2.3, we shipped a modified asyncore.py > MTK> with Medusa that handled EINTR, but in Zope 2.4 we used stock > MTK> Python's asyncore which does NOT handle EINTR being returned > MTK> from select(). IMHO, the distributed Python 2.1 asyncore > MTK> behavior is incorrect. > > This is fixed in Python 2.2. > > [...] -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: EINTR ... was Re: [Zope-dev] browser closing connection
Replace your Python 2.1.1 asyncore.py with the one that is attached. I've been using it for months now with no problems. Notice, however, that it doesn't work on WinNT, b/c the author didn't know what EINTR looked like on NT Leonardo Rochael Almeida wrote: > So, which is the "official" way of fixing Zope 2.4.3? wait for a hotfix? > apply Matthew's patch? steal asyncore from Python 2.2? > > On Tue, 2001-12-11 at 12:52, Jeremy Hylton wrote: > >>>"MTK" == Matthew T Kromer <[EMAIL PROTECTED]> writes: >>> >> MTK> For what its worth, I tracked this down in the sources and >> MTK> confirmed that in Zope 2.3, we shipped a modified asyncore.py >> MTK> with Medusa that handled EINTR, but in Zope 2.4 we used stock >> MTK> Python's asyncore which does NOT handle EINTR being returned >> MTK> from select(). IMHO, the distributed Python 2.1 asyncore >> MTK> behavior is incorrect. >> >>This is fixed in Python 2.2. >> >>[...] >> > # -*- Mode: Python; tab-width: 4 -*- # $Id: asyncore.py,v 1.1.1.3 2001/02/08 13:08:34 tdickenson Exp $ # Author: Sam Rushing <[EMAIL PROTECTED]> # == # Copyright 1996 by Sam Rushing # # All Rights Reserved # # Permission to use, copy, modify, and distribute this software and # its documentation for any purpose and without fee is hereby # granted, provided that the above copyright notice appear in all # copies and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of Sam # Rushing not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. # # SAM RUSHING DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN # NO EVENT SHALL SAM RUSHING BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS # OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, # NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN # CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. # == import exceptions import select import socket import string import sys import os if os.name == 'nt': EWOULDBLOCK = 10035 EINPROGRESS = 10036 EALREADY= 10037 ECONNRESET = 10054 ENOTCONN= 10057 ESHUTDOWN = 10058 EINTR = 0 # what should this be? else: from errno import EALREADY, EINPROGRESS, EWOULDBLOCK, ECONNRESET from errno import ENOTCONN, ESHUTDOWN, EINTR try: socket_map except NameError: socket_map = {} class ExitNow (exceptions.Exception): pass DEBUG = 0 def poll (timeout=0.0, map=None): global DEBUG if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append (fd) if obj.writable(): w.append (fd) while 1: try: r,w,e = select.select (r,w,e, timeout) except select.error, v: if v[0] != EINTR: raise else: break if DEBUG: print r,w,e for fd in r: try: obj = map[fd] try: obj.handle_read_event() except ExitNow: raise ExitNow except: obj.handle_error() except KeyError: pass for fd in w: try: obj = map[fd] try: obj.handle_write_event() except ExitNow: raise ExitNow except: obj.handle_error() except KeyError: pass def poll2 (timeout=0.0, map=None): import poll if map is None: map=socket_map # timeout is in milliseconds timeout = int(timeout*1000) if map: l = [] for fd, obj in map.items(): flags = 0 if obj.readable(): flags = poll.POLLIN if obj.writable(): flags = flags | poll.POLLOUT if flags: l.append ((fd, flags)) r = poll.poll (l, timeout) for fd, flags in r: try: obj = map[fd] try: if (flags & poll.POLLIN): obj.handle_read_event() if (flags & poll.POLLOUT): obj.handle_write_event() except ExitNow: raise ExitNow except: obj.handle_error() except KeyError: pass def loop (timeout=30.0, use_poll=0, map=None): if use_poll: poll_fun = poll2
[Zope-dev] Medusa Asyncore patch
People having problems with medusa on Linux and Solaris (particularly solaris) can try running this patch: http://www.zope.org/Members/matt/patchMedusa-asyncore.py Run it from your Zope root. It will copy asyncore.py from the python lib and patch it using the "patch" command. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZBabel Object incompatibility with Zope 2.5 b2
Hi! This time I need some specialists to help ... Here is some code from ZBabel Objects. ZBabel objects are folders that hold localized versions of anything you want to internationalize and pass getting attributes and calling objects to one of these localized versions depending on your language choice. In Zope 2.4 this works fine. But with Zope 2.5 b2 there are recursion problems: class ZBabelObject(Folder): '''ZBabelObject class ''' . def __getattr__(self, name): '''__getattr__(self, name) --> try to get an attribute from the localized object; return attr''' if name[0] != '_' and not self._v_alreadyLooking: try: self._v_alreadyLooking = 1 trueObject = self._getTrueObject() if hasattr(trueObject, name): return Rewrapper((trueObject.getId(), name)) <= HERE THE REWRAPPER IS CALLED #return getattr(trueObject, name) finally: self._v_alreadyLooking = 0 return Base.__getattr__(self, name) Look at the code above: the __getattr__ code calls the Rewrapper to make sure that the object gets the right context. If you replace the line by the commented-out one, the attributes work, but calling the object will not work. E.g., an image width or height will be passed fine, but calling the image will cause an authorization request even for managers. It seems as though __call__ will look for some security assertions via __getattr__ (?), but can't find them due to the missing wrapper. I have no clue. Here is the Rewrapper code: class Rewrapper(Base): def __init__(self, path): self._path = path def __of__(self, parent): ob = parent for p in self._path: ob = getattr(ob, p) <= HERE WE GET A RECURSION ERROR return ob When the code is run unchanged with 2.5, we get an infinite recursion (well, Zope halts it after a few recursions) at the marked line, which is bad. Does anybody have a clue why that happens NOW, and what has change in that respect from 2.4 to 2.5? Maybe there are alternative implementations? The aim is that the localized object just behaves like a normal image, DTML Method, whatever, but actually maps to different contained object versions. BTW: The full code is available here: http://cvs.iuveno-net.de/CVS/cvsweb.cgi/ZBabel/ZBabelObject.py Joachim ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: EINTR ... was Re: [Zope-dev] browser closing connection
> "JZ" == John Ziniti <[EMAIL PROTECTED]> writes: JZ> Replace your Python 2.1.1 asyncore.py with the one that is JZ> attached. I've been using it for months now with no problems. JZ> Notice, however, that it doesn't work on WinNT, b/c the author JZ> didn't know what EINTR looked like on NT The asyncore.py in Python 2.2 has a number of bug fixes and improvements over 2.1.1 and over the patched version you attached. It does, for example, work correctly on win32. I'd recommend grabbing a copy of asyncore.py from a Python 2.2 beta and using it. Jeremy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZBabel Object incompatibility with Zope 2.5 b2
Joachim Werner wrote: > >class Rewrapper(Base): > >def __init__(self, path): >self._path = path > >def __of__(self, parent): >ob = parent >for p in self._path: >ob = getattr(ob, p) <= HERE WE GET A RECURSION ERROR >return ob > > OK, I think this is somthing similar to what Martijn Faassen was seeing where its causing an acquisition wrapper to be wrapped with itself. I'm thinking about it right now. As an experiment, try setting ZOPE_SECURITY_POLICY=PYTHON before starting Zope and see if you still get the error. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] User Groups
I've found that it would be very useful to be able to define groups of users and then grant a local role to that group rather than individual users. For example we have multiple groups working together on our Zope installation and there are certian objects my group may want to share with another group. We can grant all the members of that group permission, however if they hire someone new they have to notify the maintainers of every object their group has access to. Are there plans for anything to solve this problem? The idea implementation I see would be a centralized group management system (maybe in the control panel) and then ability to grant roles to the group. But this would require changing core pieces of Zope. Any ideas on implementation? --Brian Brinegar ECN Web Technician MSEE 104 A 494-3106 http://www.geeksoft.net/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] more than one user: zope 'hangs'
On 11 Dec 2001 at 15:30, Stephan Herschel wrote: > We have got a funny problem in Zope: if user A issues a long-running > query user B also has to wait in the meantime - zope just waits for A's > query to finish. Bob's original design made gvibDA use ThunkedTM So I believe it is serialized. I think the reason for using Thunked was because under Windows, gds is not truly multi-threaded and dies. I do not recall exactly what the story is.. You're welcome to try it without the Thunked Mixin. Brad Clements,[EMAIL PROTECTED] (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZBabel Object incompatibility with Zope 2.5 b2
Doesn't seem to make any difference :-( What does that option do? > > > >class Rewrapper(Base): > > > >def __init__(self, path): > >self._path = path > > > >def __of__(self, parent): > >ob = parent > >for p in self._path: > >ob = getattr(ob, p) <= HERE WE GET A RECURSION ERROR > >return ob > > > > > > OK, > > I think this is somthing similar to what Martijn Faassen was seeing > where its causing an acquisition wrapper to be wrapped with itself. > > I'm thinking about it right now. > > As an experiment, try setting ZOPE_SECURITY_POLICY=PYTHON before > starting Zope and see if you still get the error. > > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZBabel Object incompatibility with Zope 2.5 b2
Joachim Werner wrote: >Doesn't seem to make any difference :-( > >What does that option do? > > >>>class Rewrapper(Base): >>> >>> def __init__(self, path): >>> self._path = path >>> >>> def __of__(self, parent): >>> ob = parent >>> for p in self._path: >>> ob = getattr(ob, p) <= HERE WE GET A RECURSION ERROR >>> return ob >>> >>> >>OK, >> >>I think this is somthing similar to what Martijn Faassen was seeing >>where its causing an acquisition wrapper to be wrapped with itself. >> >>I'm thinking about it right now. >> >>As an experiment, try setting ZOPE_SECURITY_POLICY=PYTHON before >>starting Zope and see if you still get the error. >> >> > Turning on ZOPE_SECURITY_POLICY=PYTHON in the environment activates the older Python security machinery rather than the C accelerated machinery. If the problem dissapears then, its a problem with the C implementation. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] recipe for trapping SIGSEGV and SIGILL signals on solaris
At Tue, 11 Dec 2001 10:42:46 -0500, Matthew T. Kromer wrote: > > > >#0 0xef5b9810 in _lwp_sema_wait () > >(gdb) info threads > > 19 Thread 10 0xef5b9810 in _lwp_sema_wait () > > 18 Thread 9 0xef5b9810 in _lwp_sema_wait () > > 17 Thread 8 0xef5b9810 in _lwp_sema_wait () > > 16 Thread 7 (LWP 8) subtract_refs (containers=0x13dec8) > >at ./Modules/gcmodule.c:166 > > > > Aha! See? > Matthew - I performed the operations that you recommended and here are the results (see below). The problem seems to be with the value of the tp_traverse field. I am not aware of any "T" type python object. I'm wondering if this is an extension class type (just a guess). I searched through all of the *.c files in zope, etc. but I as not able to find any type of name "T". I also ran across a bug posting at sourceforge ... http://sourceforge.net/tracker/?func=detail&atid=105470&aid=471942&group_id=5470 This bug report looks very similiar. - j #0 0xef5b9810 in _lwp_sema_wait () (gdb) info threads 19 Thread 10 0xef5b9810 in _lwp_sema_wait () 18 Thread 9 0xef5b9810 in _lwp_sema_wait () 17 Thread 8 0xef5b9810 in _lwp_sema_wait () 16 Thread 7 (LWP 8) subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 15 Thread 6 0xef647cac in _swtch () 14 Thread 5 0xef5b9810 in _lwp_sema_wait () 13 Thread 4 (LWP 0) 0xef647b7c in _swtch () 12 Thread 3 0xef647cac in _swtch () 11 Thread 2 (LWP 2) 0xef5b9958 in _signotifywait () 10 Thread 1 (LWP 6) 0xef5b7488 in _poll () 9 LWP9 0xef5b6a24 in door_restart () 8 LWP8 subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 7 LWP7 0xef5b9810 in _lwp_sema_wait () 6 LWP6 0xef5b7488 in _poll () 5 LWP5 0xef5b9814 in _lwp_sema_wait () 4 LWP4 0xef5b9810 in _lwp_sema_wait () 3 LWP3 0xef5b9810 in _lwp_sema_wait () 2 LWP2 0xef5b9958 in _signotifywait () * 1 LWP1 0xef5b9810 in _lwp_sema_wait () (gdb) thread 16 [Switching to Thread 7 (LWP 8)] #0 subtract_refs (containers=0x13dec8) at ./Modules/gcmodule.c:166 ./Modules/gcmodule.c:166: No such file or directory. (gdb) print *((PyObject *) gc)->ob_type $1 = {ob_refcnt = 18213696, ob_type = 0x2d70b0, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4156348, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0x3adeb0, tp_as_number = 0xf66198, tp_as_sequence = 0xdf3fa0, tp_as_mapping = 0x0, tp_hash = 0x1, tp_call = 0x144490 , tp_str = 0x3f0a1c, tp_getattro = 0x125865c, tp_setattro = 0x3c1b04, tp_as_buffer = 0x0, tp_flags = 158561192, tp_doc = 0x29 "", tp_traverse = 0x4c4f4144, tp_clear = 0xd908c0, tp_richcompare = 0x1151300, tp_weaklistoffset = 0} (gdb) print *((PyObject *) 0x2d70b0)->ob_type $2 = {ob_refcnt = 2977968, ob_type = 0xff5b80, ob_size = 0, tp_name = 0x1 "T", tp_basicsize = 1328272, tp_itemsize = 4155228, tp_dealloc = 0x125865c, tp_print = 0x3c1b04, tp_getattr = 0, tp_setattr = 0, tp_compare = 0x29, tp_repr = 0, tp_as_number = 0x1212b48, tp_as_sequence = 0xbf8d30, tp_as_mapping = 0x, tp_hash = 0x1, tp_call = 0x144490 , tp_str = 0x4ab2cc, tp_getattro = 0x1089d5c, tp_setattro = 0x4ab30c, tp_as_buffer = 0x0, tp_flags = 0, tp_doc = 0x29 "", tp_traverse = 0, tp_clear = 0x122d140, tp_richcompare = 0x11ccd70, tp_weaklistoffset = -1} gdb) x 0x4c4f4144 0x4c4f4144: Cannot access memory at address 0x4c4f4144. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Medusa Asyncore patch
Hi, after applying the patch zope won't restart correclty for my version. (python 2.1.1, zope 2.4.3) Traceback: 2001-12-12T07:45:49 PANIC(300) z2 Startup exception Traceback (innermost last): File z2.py, line 625, in ? File /usr/src/packages/BUILD/Zope-2.4.3-src/ZServer/HTTPServer.py, line 396, in __init__ File /usr/src/packages/BUILD/Zope-2.4.3-src/ZServer/medusa/http_server.py, line 562, in __init__ File /usr/src/packages/BUILD/Zope-2.4.3-src/ZServer/HTTPServer.py, line 410, in create_socket TypeError: unbound method create_socket() must be called with instance as first ar gument Dirk - Original Message - From: "Matthew T. Kromer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 5:50 PM Subject: [Zope-dev] Medusa Asyncore patch > > People having problems with medusa on Linux and Solaris (particularly > solaris) can try running this patch: > > http://www.zope.org/Members/matt/patchMedusa-asyncore.py > > Run it from your Zope root. It will copy asyncore.py from the python > lib and patch it using the "patch" command. > > > ___ > Zope-Dev maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )