Re: [Zope-dev] Modifying a menu

2002-03-14 Thread Adrian Hungate

If you want to remove (Hide) items in this menu, the easiest way is to
download my PatchKit product ( http://www.zope.org/Members/haqa/PatchKit )
which allows you to choose items to hide from the "select..." list.

If you want to add items to the list, the easiest way is to look around
Zope.org's Products section ( http://www.zope.org/Products ) which contains
MANY products that you can add to the list simply by installing them.

Hope this helps, and hope you enjoy learning and using Zope. (I did, and
still do!)

Adrian...

--
The difficulty of tactical maneuvering consists in turning the devious into
the direct, and misfortune into gain.
- Sun Tzu


- Original Message -
From: "Marcia Perry" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 15, 2002 3:02 AM
Subject: [Zope-dev] Modifying a menu


> Hi,
>
> Where in the Zope src is the menu labeled "Select type to add..." created?
>
> We want to change this pulldown menu but I'm not familiar w/ the Zope
> src code.  I started w/ the obvious: after pointing my browser at http://
> myhost:8080/manage and getting the Zope page, I did Netscape -> View ->
> Page Source and see the 3 frames.  I think the menu I'm interested in
> is in the frame w/ src="http://myhost:8080/manage_workspace"; w/ name=
> "manage_main".  So I searched thru. the src, grep'ng for some strings
> and located "manage_main" in ZopePageTemplate.py.  But that's as far
> as I got.  I'm new to Zope, don't have time to step thru. all the code,
> but gotta dive in and make some changes to this menu.
>
> Please help! And if there's some documentation that describes the code,
> I'd be stoked.
>
> Thanks,
> -- marc
> 
> Marc Perry  [EMAIL PROTECTED]
> Lawrence Berkeley National Laboratory   WORK#  (510) 486-6786
> 1 Cyclotron RoadFAX#   (510) 486-6363
> Berkeley, CA 94720 MS: 50A-3111
>
> ___
> 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: [Zope-dev] Modifying a menu

2002-03-14 Thread Max M

Marcia Perry wrote:

>Where in the Zope src is the menu labeled "Select type to add..." created?
>
Generally you cannot change this menu. At least not in the standard Zope 
management interface. A Zope with a management interface that was 
handicapped in this way could also be pretty dangerous.

You can however do it in your own products. So if you want your user to 
be able to only add some kind of objetcs in a folder, you create a 
ZClass or a Python products. Then you can decide which products can be 
added to your own folder.

If you create a ZClass you should just subclass ObjectManager, and then 
inside the product there will be a tab called "Subobjects" where you can 
select possible "legal" objects that the user can add.

-

If you really want to get dirty. Which I would *strongly* advice 
against, you must look in:

\lib\python\OFS\ObjectManager.py

and overwrite "all_meta_types()". This functions returns a list of 
tuples, telling which objects to be added to the "add *" selectbox.

But it WILL bite you later.

For further info google for "meta_types" and "all_meta_types"

regards Max M


___
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 )



AW: [Zope-dev] Modifying a menu

2002-03-14 Thread buelent aldemir

ZOPEINSTANCE/lib/python/OFS/dtml/main.dtml

greetings buelent

___
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 on the segfault saga

2002-03-14 Thread Anthony Baxter


>>> Dieter Maurer wrote
> Just a wild guess: is the GC guaranteed to be thread safe?

Yep. 

The GC is _almost_ certainly not the problem here - it's just that the
GC is the poor bunny that has to walk through the objects in memory. So
when something's been mangled, the GC is the thing that falls over and
breaks.

I think I've mentioned it before, but looking at the object _before_
the corrupted one in memory might be a useful thing to try...

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>   
It's never to late to have a happy childhood.


___
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] Modifying a menu

2002-03-14 Thread Marcia Perry

Hi,

Where in the Zope src is the menu labeled "Select type to add..." created?

We want to change this pulldown menu but I'm not familiar w/ the Zope
src code.  I started w/ the obvious: after pointing my browser at http://
myhost:8080/manage and getting the Zope page, I did Netscape -> View ->
Page Source and see the 3 frames.  I think the menu I'm interested in
is in the frame w/ src="http://myhost:8080/manage_workspace"; w/ name=
"manage_main".  So I searched thru. the src, grep'ng for some strings
and located "manage_main" in ZopePageTemplate.py.  But that's as far
as I got.  I'm new to Zope, don't have time to step thru. all the code,
but gotta dive in and make some changes to this menu.

Please help! And if there's some documentation that describes the code,
I'd be stoked.

Thanks,
-- marc

Marc Perry  [EMAIL PROTECTED]
Lawrence Berkeley National Laboratory   WORK#  (510) 486-6786
1 Cyclotron RoadFAX#   (510) 486-6363
Berkeley, CA 94720  MS: 50A-3111

___
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 on the segfault saga

2002-03-14 Thread Leonardo Rochael Almeida

Hi Matt,

I'll wait for the patch where you also silence the dead-raising area in
ExtensionClass.

What if, instead of detecting this situation, we try to detect if the 
incref is happening without the interpreter lock held? increfs and
decrefs shouldn't be happening freely and simultaneously even in C code
right? Is holding the interpreter lock the correct way to signal that
you'll be doing increfings and decrefings in C code?

Cheers, Leo

On Thu, 2002-03-14 at 19:10, Matthew T. Kromer wrote:
> Attached is another diagnostic patch which you might apply to Python. 
>  If you apply this patch, you WILL need to rebuild Zope to include it.
> 
> What it will do is complain to stderr if an object is INCREF'd from 
> refcount 0.  It also silences the complaint for the one area which I 
> know revives dead objects.
> 
> This patch will probably cause a crash after an erroneous incref-from-0 
> is detected, since it doesnt actually DO the incref in that case.
> 
> The intent is to find a case in the code where an object is held between 
> threads; one thread decrefs to zero, the other thread increfs, causing a 
> revive -- but too late to save the patient.
> 
> -- 
> Matt Kromer
> Zope Corporation  http://www.zope.com/ 
> 
> 
> 
> 

> --- Include/object.h.orig Thu Mar 14 16:44:36 2002
> +++ Include/object.h  Thu Mar 14 16:54:29 2002
> @@ -442,7 +442,7 @@
>  #define _Py_NewReference(op) ((op)->ob_refcnt = 1)
>  #endif
>  
> -#define Py_INCREF(op) ((op)->ob_refcnt++)
> +#define Py_INCREF(op) ((op)->ob_refcnt > 0 ? (op)->ob_refcnt++ : 
>fprintf(stderr,"Eeek! Increfing an object from refct 0 at %s:%d\n",__FILE__,__LINE__) 
>)
>  #define Py_DECREF(op) \
>   if (--(op)->ob_refcnt != 0) \
>   ; \
> --- Objects/classobject.c.origThu Mar 14 17:04:40 2002
> +++ Objects/classobject.c Thu Mar 14 17:01:36 2002
> @@ -535,7 +535,8 @@
>  #endif
>  #else /* !Py_TRACE_REFS */
>   /* Py_INCREF boosts _Py_RefTotal if Py_REF_DEBUG is defined */
> - Py_INCREF(inst);
> + /* Py_INCREF(inst); */
> + inst->ob_refcnt++;  /* we dont want to trap this one */
>  #endif /* !Py_TRACE_REFS */
>  
>   /* Save the current exception, if any. */
-- 
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: [Zope-dev] more on the segfault saga

2002-03-14 Thread Matthew T. Kromer

Matthew T. Kromer wrote:

> Attached is another diagnostic patch which you might apply to Python. 
> If you apply this patch, you WILL need to rebuild Zope to include it.
>
> What it will do is complain to stderr if an object is INCREF'd from 
> refcount 0.  It also silences the complaint for the one area which I 
> know revives dead objects.
>
> This patch will probably cause a crash after an erroneous 
> incref-from-0 is detected, since it doesnt actually DO the incref in 
> that case.
>
> The intent is to find a case in the code where an object is held 
> between threads; one thread decrefs to zero, the other thread increfs, 
> causing a revive -- but too late to save the patient.


extensionclass also brings back the dead; the following patch to Zope's 
extensionclass will turn off the warning when it happens when you apply 
the previous patch that I sent out that complains when an object is 
incref'd from a refcount of zero.


-- 
Matt Kromer
Zope Corporation  http://www.zope.com/ 




Index: lib/Components/ExtensionClass/src/ExtensionClass.c
===
RCS file: /cvs-repository/Zope/lib/Components/ExtensionClass/src/ExtensionClass.c,v
retrieving revision 1.46.36.1
diff -u -r1.46.36.1 ExtensionClass.c
--- lib/Components/ExtensionClass/src/ExtensionClass.c  4 Oct 2001 14:25:19 -  
 1.46.36.1
+++ lib/Components/ExtensionClass/src/ExtensionClass.c  14 Mar 2002 22:43:10 -
@@ -3047,8 +3047,9 @@
   fprintf(stderr,"Deallocating a %s\n", self->ob_type->tp_name);
 #endif
 
+  self->ob_refcnt++;
   PyErr_Fetch(&t,&v,&tb);
-  Py_INCREF(self); /* Give us a new lease on life */
+ /* Py_INCREF(self);   /* Give us a new lease on life */
 
   if (subclass_watcher &&
  ! PyObject_CallMethod(subclass_watcher,"destroying","O",self))



Re: [Zope-dev] more on the segfault saga

2002-03-14 Thread Matthew T. Kromer

Attached is another diagnostic patch which you might apply to Python. 
 If you apply this patch, you WILL need to rebuild Zope to include it.

What it will do is complain to stderr if an object is INCREF'd from 
refcount 0.  It also silences the complaint for the one area which I 
know revives dead objects.

This patch will probably cause a crash after an erroneous incref-from-0 
is detected, since it doesnt actually DO the incref in that case.

The intent is to find a case in the code where an object is held between 
threads; one thread decrefs to zero, the other thread increfs, causing a 
revive -- but too late to save the patient.

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/ 




--- Include/object.h.orig   Thu Mar 14 16:44:36 2002
+++ Include/object.hThu Mar 14 16:54:29 2002
@@ -442,7 +442,7 @@
 #define _Py_NewReference(op) ((op)->ob_refcnt = 1)
 #endif
 
-#define Py_INCREF(op) ((op)->ob_refcnt++)
+#define Py_INCREF(op) ((op)->ob_refcnt > 0 ? (op)->ob_refcnt++ : 
+fprintf(stderr,"Eeek! Increfing an object from refct 0 at %s:%d\n",__FILE__,__LINE__) 
+)
 #define Py_DECREF(op) \
if (--(op)->ob_refcnt != 0) \
; \
--- Objects/classobject.c.orig  Thu Mar 14 17:04:40 2002
+++ Objects/classobject.c   Thu Mar 14 17:01:36 2002
@@ -535,7 +535,8 @@
 #endif
 #else /* !Py_TRACE_REFS */
/* Py_INCREF boosts _Py_RefTotal if Py_REF_DEBUG is defined */
-   Py_INCREF(inst);
+   /* Py_INCREF(inst); */
+   inst->ob_refcnt++;  /* we dont want to trap this one */
 #endif /* !Py_TRACE_REFS */
 
/* Save the current exception, if any. */



Re: [Zope-dev] more on the segfault saga

2002-03-14 Thread Leonardo Rochael Almeida

On Thu, 2002-03-14 at 17:17, Dieter Maurer wrote:
> Leonardo Rochael Almeida writes:
>  > In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
>  > crashes in pure dtml methods, which could mean that PythonScripts are
>  > inocent in this case... or not, since the segfault hits inside the gc,
>  > which might be collecting something completely unrelated to the current
>  > requests.
> Just a wild guess: is the GC guaranteed to be thread safe?

The gc acquires the big interpreter lock before doing it's stuff. which
is not the same thing, since C code could be doing bad stuff. Question,
how the gc differentiates between an unreachable object and an object
that's reachable only by C code?

-- 
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: [Zope-dev] Marshalling of records in REQUEST.form

2002-03-14 Thread Jean Jordaan

Hi Dieter

Roughly, I do this:

  FSSession.set('query_form', REQUEST.form)
  ... 
  context.log('query_form: %s'%FSSession(query_form))

where the 'log' external method is:

  import zLOG
  def log(message,summary='',severity=0):
  zLOG.LOG('MyDebugLog',severity,summary,message)

The output I quoted in the previous message appears in the logfile. My
Zope is 2.4.3

-- 
Jean Jordaan
Upfront Systems http://www.upfrontsystems.co.za


___
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 on the segfault saga

2002-03-14 Thread Matthew T. Kromer

Dieter Maurer wrote:

>Leonardo Rochael Almeida writes:
> > In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
> > crashes in pure dtml methods, which could mean that PythonScripts are
> > inocent in this case... or not, since the segfault hits inside the gc,
> > which might be collecting something completely unrelated to the current
> > requests.
>Just a wild guess: is the GC guaranteed to be thread safe?
>
>
>Dieter
>

I'm fairly sure it is; certainly, there's an activity flag which should 
prevent the collector from being reentered.

-- 
Matt Kromer
Zope Corporation  http://www.zope.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] Marshalling of records in REQUEST.form

2002-03-14 Thread Dieter Maurer

Jean Jordaan writes:
 > I've just noticed this. In my form I have, for example:
 > 
 >  
 >  
 >  
 >  
 >  
 > 
 > When I log this after submission, I see:
 > 
 >  {'HostType': ['Sequential'], 'properties_to_show': ContactPerson: 
 >  ['ContactName', 'DirectEmail'], Customer: ['CustomerName', 
 >  'CustomerStatus']}
Where are you looking at?

When I look at "REQUEST.form", I see:

 {
 'P.N' : ['N1', 'N2'],
 'P.C' : ['C1', 'C2']
 }

(with shortened names). I.e. I see what I expect to see.

My Zope is 2.5.0 (CVS version from end of Jan 2002).


Dieter

___
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 on the segfault saga

2002-03-14 Thread Dieter Maurer

Leonardo Rochael Almeida writes:
 > In any event, Martijn Jacobs (a.k.a. instability case #3 :-) sees his
 > crashes in pure dtml methods, which could mean that PythonScripts are
 > inocent in this case... or not, since the segfault hits inside the gc,
 > which might be collecting something completely unrelated to the current
 > requests.
Just a wild guess: is the GC guaranteed to be thread safe?


Dieter

___
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] Bug days

2002-03-14 Thread Matt Behrens

Brian Lloyd wrote:

> In an effort to better keep up with the collector, I'd like
> to throw out the idea of doing periodic "bug days" (a la 
> the mozilla bug days), where Zope geeks and committers would 
> get together on IRC and spend a few hours knocking out issues.

Yes, this would be *very* cool, if for no other reason than to try to 
thin out the Collector.  I made one pass over it today and found a few 
that never got closed when resolved, etc.  What several of them seemed 
to fall into, though, were ones that really merited a discussion of some 
sort to resolve, preferably with a senior engineer of some sort present 
to at least bounce ideas off.

>   - Given the wide geographic area that committers (and patch 
> submitters) cover, what is a good time of day for a bug 
> day to start / end (where start and end are always going 
> to be fuzzy, of course).

I'm sure I could swing a weekday every once in awhile (during the 
workday, EST) at work.

>   - Would it be better for bugdays to be ad-hoc, or should we 
> try to set up regularly-scheduled bugdays at some reasonable 
> interval? If the latter, we need to come up with a day / time 
> that is agreeable to as many of the committers as possible.

Better make 'em scheduled, or no-one will show. :-)

___
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] Zope 2.6 planning - call for contributors!

2002-03-14 Thread Behrens Matt - Grand Rapids

Behrens Matt - Grand Rapids wrote:

> This isn't exciting by any means unless you're one of the people who 
> package Zope up for distribution, or maybe you're one of the people who 
> manage lots of little Zopes on one system; but I'd like to revive the 
> "grand unified Zope installation and control" proposal that has been 
> floated by many people (including me) in one form or another for some 
> time

FYI, everyone who's following this: I have hijacked 
http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration 
for this purpose. :-)

___
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 on the segfault saga

2002-03-14 Thread Jim Washington

Don't know if this helps, but the last three segfaults I have seen were 
right after someone logs in, during loading /manage.

Zope-2.5.0 Win32 binary on Win2k. The pop-up referenced the same 
instruction "0x1e13490a" at the same memory address "0x005c" all 
three times, saying 'memory could not be "read".'

-- Jim Washington


___
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] Bug days

2002-03-14 Thread Brian Lloyd

Hi all - 

In an effort to better keep up with the collector, I'd like
to throw out the idea of doing periodic "bug days" (a la 
the mozilla bug days), where Zope geeks and committers would 
get together on IRC and spend a few hours knocking out issues.

I've drafted a preliminary bug day manifesto that describes 
how it would work in a little more detail:

  http://dev.zope.org/CVS/BugDays

I'd like to hear what people think, as well as work out a few 
logistics:

  - Given the wide geographic area that committers (and patch 
submitters) cover, what is a good time of day for a bug 
day to start / end (where start and end are always going 
to be fuzzy, of course).

  - Would it be better for bugdays to be ad-hoc, or should we 
try to set up regularly-scheduled bugdays at some reasonable 
interval? If the latter, we need to come up with a day / time 
that is agreeable to as many of the committers as possible.

Thoughts?

-Brian


___
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 on the segfault saga

2002-03-14 Thread Leonardo Rochael Almeida

5On Thu, 2002-03-14 at 13:28, Matthew T. Kromer wrote:
> 
> OK, I'm attaching a patch to Python's Modules/gcmodule.c which should 
> set a trap for where the garbage collector trips over bad data; this 
> will grab the bad data and send it to stderr so I can build a better trap.

I'm on it. Will send results when they're available. If anyone wants to
talk to me during the period, I'll be on IRC.

-- 
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: [Zope-dev] more on the segfault saga

2002-03-14 Thread Matthew T. Kromer

Leonardo Rochael Almeida wrote:

>On Wed, 2002-03-13 at 21:30, Matthew T. Kromer wrote:
>
>>On Wednesday, March 13, 2002, at 10:40 AM, Leonardo Rochael Almeida 
>>wrote:
>>
>>>What about patching Python to report the freed objects like you
>>>mentioned on IRC? Also, how about turning on some flags in
>>>gc.seg_debug()? Do you think we might be able to glance something by
>>>seeing what objects where logged as freed or by storing them in
>>>gc.garbage?
>>>
>
>setting gc.set_debug(gc.DEBUG_LEAK) floods your stderr in a way you can
>only believe by seeing it. And it didn't give me any clue. the last
>object freed was an instance method. Most everything running inside Zope
>is an instance method or another...
>

OK, I'm attaching a patch to Python's Modules/gcmodule.c which should 
set a trap for where the garbage collector trips over bad data; this 
will grab the bad data and send it to stderr so I can build a better trap.

This is ONLY step one in tracking this down.  You will have to rebuild 
Python to activate this patch; and all it basically is doing is setting 
a SIGSEGV handler; and setting up a small trace area for the GC to 
record data in to, so at the time the SIGSEGV comes in, it can print out 
what the last thing was the code was doing.

This is ONLY going to tell me that the GC tripped over something, but it 
WILL at least tell me what object it is scanning, that object's refcount 
(which I bet is zero, and forms the basis for a better trap) and the 
object's type and traverse pointers.

The traverse pointer should NOT be null.  If it is, then thats something 
wrong with gc being called for that type.

If you apply this patch, run Zope with a python with this patch applied 
with stderr saved to a file.  send me the file, and then you can revert 
to running zope w/o the patch.

When the patch triggers, it will exit Python immediately with exit code 
999 after it prints its information.


-- 
Matt Kromer
Zope Corporation  http://www.zope.com/ 




--- Modules/gcmodule.c.orig Thu Mar 14 10:35:21 2002
+++ Modules/gcmodule.c  Thu Mar 14 11:14:13 2002
@@ -22,6 +22,8 @@
 #include "Python.h"
 
 #ifdef WITH_CYCLE_GC
+#include 
+#include 
 
 /* magic gc_refs value */
 #define GC_MOVED -1
@@ -34,6 +36,7 @@
 static PyGC_Head generation2 = {&generation2, &generation2, 0};
 static int generation = 0; /* current generation being collected */
 
+
 /* collection frequencies, XXX tune these */
 static int enabled = 1; /* automatic collection enabled? */
 static int threshold0 = 700; /* net new containers before collection */
@@ -60,12 +63,82 @@
DEBUG_SAVEALL
 static int debug;
 
+
+static int CRASHTRAP = 0;
+static int CRASHFLAG = 0;
+static char *CRASHTYPE = NULL;
+static int CRASHLOG[16];
+
 /* list of uncollectable objects */
 static PyObject *garbage;
 
 /* Python string to use if unhandled exception occurs */
 static PyObject *gc_str;
 
+static void CRASH_trip(int i, siginfo_t *siginfo, void *p) {
+
+   int n;
+
+   fprintf(stderr,"CRASH %d at %08x\n", (int) siginfo->si_signo,
+   (unsigned int) siginfo->si_addr);
+
+   if (CRASHFLAG == 0) {
+   fprintf(stderr,"\tCrash handler not activated for this!\n");
+   } else {
+   fprintf(stderr,"\tCrash type %s\n", CRASHTYPE ? CRASHTYPE : "(none)");
+   fprintf(stderr,"\tCrash log: %d values: ", CRASHLOG[0]);
+   for (n = 0; n < CRASHLOG[0]; n++) {
+   fprintf(stderr," %08x", (unsigned int) CRASHLOG[n+1]);
+   }
+   fprintf(stderr,"\n");
+   }
+   exit(999);
+}
+
+static void CRASH_activate(void) {
+
+   struct sigaction sa;
+   struct sigaction oldsa;
+
+   sa.sa_sigaction = CRASH_trip;
+   sigemptyset(&sa.sa_mask);
+   sa.sa_flags = SA_SIGINFO;
+
+   if (CRASHTRAP == 0) {
+   sigaction(SIGSEGV, &sa, &oldsa); 
+   CRASHTRAP = 1;
+   }
+
+   CRASHFLAG = 1;
+   CRASHTYPE = NULL;
+   CRASHLOG[0] = 0;
+
+}
+
+static void CRASH_deactivate(void) {
+   CRASHFLAG = 0;
+}
+
+static void CRASH_type(char *s) {
+   CRASHTYPE = s;
+}
+
+static void CRASH_record(int n, ...) {
+   va_list ap;
+   int i;
+
+   va_start(ap, n);
+
+   for (i = 0; i < n; i++) {
+   CRASHLOG[i+1] = va_arg(ap, int);
+   }
+
+   va_end(ap);
+
+   CRASHLOG[0] = n;
+}
+
+
 /*** list functions ***/
 
 static void
@@ -164,13 +237,29 @@
 subtract_refs(PyGC_Head *containers)
 {
traverseproc traverse;
+   PyObject *obj;
+
+
PyGC_Head *gc = containers->gc_next;
+
+   CRASH_activate();
+   CRASH_type("subtract_refs");
+
for (; gc != containers; gc=gc->gc_next) {
+   obj = (PyObject *)PyObject_FROM_GC(gc);
+   CRASH_record(4, obj,
+   obj != 0 ? obj->ob_refcnt : 0,
+   obj != NULL ? obj->ob_type : NULL,
+   obj != NULL && ob

Re: [Zope-dev] Memory Leak Problem

2002-03-14 Thread Andre Schubert

Andre Schubert schrieb:

If have changed the that it skips the ZSQLMethod and sends the query
used in the ZSQLMethod direct
to the manage_test function from the ZPsycopgDA with the result that
zope grows up
after running the script.
If it is possible that the mem-leak is somewhere in the DA, then i post
this message to the psycopg mailinglist.

Thanks

> 
> Hi all,
> 
> I have isolated the memory leak problem on a naked 2.3.3 Zope.
> I have on ZPsycopgDA and two SQL Methods, one SQL Method contains
> DTML-IFs and DTML-ELSEs and REQUEST.sets
> the other SQL Method contains the rendered query of the first, this
> means there is pure sql in it.
> Both methods cache there results 60 secs.
> Zope runs with 4 threads.
> 
> I wrote a test-script wich opens 4 threads and each thread call the
> second SQL Methods "manage_test" via wget.
> 
> After a restart my zope-processes are around 12MB.
> Then i start my script and before i receive any result all processes are
> grown up to 26MB.
> 
> Even if after i start my script nothing happens, but before i receive
> the result the processes grow up,
> maybe i think this is the time where zope gets the results from the
> database and
> "puts" it into the Results-Class( i am right at this point ?).
> 
> But is the problem in the ZSQLMethod( where the results were cached ) or
> the ZPsycopgDA ??
> 
> Regards,
> 
> --
> Andre SchubertEMail:   [EMAIL PROTECTED]
>   Tel: 03774 6625-78
> km3 teledienst GmbH   Fax: 03774 6625-79
> 
> ___
> 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: [Zope-dev] Memory Leak Problem

2002-03-14 Thread Andre Schubert

Toby Dickenson schrieb:
> 
> On Thu, 14 Mar 2002 13:50:13 +0100, Andre Schubert
> <[EMAIL PROTECTED]> wrote:
> 
> >After a restart my zope-processes are around 12MB.
> 
> Sounds about right.
> 
> >Then i start my script and before i receive any result all processes are
> >grown up to 26MB.
> 
> Thats not unreasonable for the working set of zope. I have no reason
> to suspect a leak.
> 
> Im not sure what operating system you are using. If its linux then

RedHat Immunix 6.2

> maybe you are misinterpreting the output of ps or top: The 26M is
> listed next to each process, but its the *same* 26M in each row of the
> table. In other words, your system is using 26M total for zope, not
> 26*5 (assuming you have 5 processes).
> 
> If Zope grows by 12M for each request then thats a different scenario.
> 
> 12M growth on the *first* request is quite normal.

Yes, i believe, but every time i run that script the memory usage of
zope( all processes ) grows up.
If the script was ended and zope grows up about 1MB would i think that
each request for the ZSQL Methods grows up zope
about 250K and 250K * 4 = 1MB.
My problem is that every time after running the script zope grows up.
Sometimes zope grows up about 1 or 2MB and sometimes only 100K, but zope
is growing up every time a run my test-script.

On our production server the last time zope grows up to 100MB in 6
hours, and maybe thats not so good.

> 
> Toby Dickenson
> [EMAIL PROTECTED]
> 
> ___
> 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: [Zope-dev] Memory Leak Problem

2002-03-14 Thread Toby Dickenson

On Thu, 14 Mar 2002 13:50:13 +0100, Andre Schubert
<[EMAIL PROTECTED]> wrote:

>After a restart my zope-processes are around 12MB.

Sounds about right.

>Then i start my script and before i receive any result all processes are
>grown up to 26MB.

Thats not unreasonable for the working set of zope. I have no reason
to suspect a leak.

Im not sure what operating system you are using. If its linux then
maybe you are misinterpreting the output of ps or top: The 26M is
listed next to each process, but its the *same* 26M in each row of the
table. In other words, your system is using 26M total for zope, not
26*5 (assuming you have 5 processes).

If Zope grows by 12M for each request then thats a different scenario.

12M growth on the *first* request is quite normal.

Toby Dickenson
[EMAIL PROTECTED]

___
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] Memory Leak Problem

2002-03-14 Thread Andre Schubert

Hi all,

I have isolated the memory leak problem on a naked 2.3.3 Zope.
I have on ZPsycopgDA and two SQL Methods, one SQL Method contains
DTML-IFs and DTML-ELSEs and REQUEST.sets
the other SQL Method contains the rendered query of the first, this
means there is pure sql in it.
Both methods cache there results 60 secs.
Zope runs with 4 threads.

I wrote a test-script wich opens 4 threads and each thread call the
second SQL Methods "manage_test" via wget.

After a restart my zope-processes are around 12MB.
Then i start my script and before i receive any result all processes are
grown up to 26MB.

Even if after i start my script nothing happens, but before i receive
the result the processes grow up,
maybe i think this is the time where zope gets the results from the
database and
"puts" it into the Results-Class( i am right at this point ?).

But is the problem in the ZSQLMethod( where the results were cached ) or
the ZPsycopgDA ??

Regards,

-- 
Andre SchubertEMail:   [EMAIL PROTECTED]
  Tel: 03774 6625-78
km3 teledienst GmbH   Fax: 03774 6625-79

___
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] where is Zope 2.5.1?

2002-03-14 Thread Toby Dickenson

On 13 Mar 2002 16:44:25 -0300, Leonardo Rochael Almeida
<[EMAIL PROTECTED]> wrote:

>The problem is, as far as I could check, the crashes all happen inside
>the gc, which runs orthogonal to the requests, so getting a
>reproduceable test case is really hard.

Thinking aloud If I remember correctly (but its been a while since
I looked at the python gc) it is possible to manually force a gc
sweep.

It may (or may not ;-) be easier to spot a pattern if you force a
sweep after every request



Toby Dickenson
[EMAIL PROTECTED]

___
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] Re: more on the segfault saga

2002-03-14 Thread Martijn Jacobs


Sorry, the correct URL is http://www.coherence.nl/crash.txt
(without the dot)


martijn.




___
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] Re: more on the segfault saga

2002-03-14 Thread Martijn Jacobs


Hello again,

I have a little bit more information about our specific "crash"
environment. First of all, I looked in the Big M Log at the time of the
crashes, but couldn't find anything interesting : 8 of the 10 times it
was a dtml document containing plain stylesheet data :( I don't think
there's any usefull information in here, because the crashes are
threading related.

Second of all I managed to get a traceback (?) of a gdb session, I don't
know if it's any usefull information, I'm not a zope expert on this
area, I hope other people (zope developers?) understand what's on the
traceback. The customer was not happy with my session, but that
environment is the only one that crashes, we still cannot reproduce the
error here, nor can we make a testcase for the crash there :(

I put the traceback online on http://www.coherence.nl/crash.txt.


regards,


martijn






___
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] Marshalling of records in REQUEST.form

2002-03-14 Thread Jean Jordaan

Hi all

I've just noticed this. In my form I have, for example:

 
 
 
 
 

When I log this after submission, I see:

 {'HostType': ['Sequential'], 'properties_to_show': ContactPerson: 
 ['ContactName', 'DirectEmail'], Customer: ['CustomerName', 
 'CustomerStatus']}

In other words, not a valid dictionary. As a valid dictionary, that 
would be:

 {'HostType': ['Sequential'], 'properties_to_show': {'ContactPerson': 
 ['ContactName', 'DirectEmail'], 'Customer': ['CustomerName', 
 'CustomerStatus']}}

Is a bug or a feature? Is the reason for the representation the fact 
that 'properties_to_show' is a record, and not a dictionary?

-- 
Jean Jordaan
Upfront Systems http://www.upfrontsystems.co.za


___
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] Zope crash problem

2002-03-14 Thread Stefano Noferi

Hi
My experiences with zope 2.5.1b1 and python 2.1.2 crashes are now only with
CMF 1.1 installed.
The new system with plugin indexes implemented in zope 2.4.x (with text
fields plugin splitters compiled in c as python modules for optimization) is
a diff with stable zope 2.3.3 platform.. Can splitter modules (or eventually
other python module .so of zope core) crash zope 2.5.1b1 ?
How can I test this?

Thanks
Stefano

 --
Stefano Noferi
n o z e  S.r.l.
Soluzioni Open-Source
Via Caduti del Lavoro, 32
56122 Pisa (PI) - Italy
Tel: +39 (0)50 533320
Fax: +39 (0)50 526604
Email: [EMAIL PROTECTED]
Web: http://www.noze.it

--


___
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 )