Re: [Zope-dev] Memory Leak Problem
On Tue, 12 Mar 2002 18:38:16 +0100, Oliver Bleutgen [EMAIL PROTECTED] wrote: Acquisition.ImplicitAcquirerWrapper: 42442 That class is used to glue together acquisition content chains. Being top of the list indicates that you have been leaking an acquisition context chain. That doesnt mean that the bug relates to acquisition; acquisition just means that the leak is more severe than otherwise (because it keeps the whole context chain around). OFS.DTMLMethod.DTMLMethod: 3989 42442/3989 = 10.6. That indicates that you are leaking an acquisition chain of roughly 10 objects. ZPublisher.HTTPRequest.HTTPRequest: 3941 ZServer.HTTPResponse.ZServerHTTPResponse: 3934 ZPublisher.BaseRequest.RequestContainer: 3931 AccessControl.DTML.TemplateDict: 3930 The numbers for those objects are all roughly 3900. These objects are the ones referenced by that acquisition chain. I recommend you look further down that list, until you find a number that is much less than 3900. All of the objects above that mark are pieces of the jigsaw puzzle that will tell you *what* is being leaked. Thats where I would start meditating to work out *how* its being leaked. doesn't surely look too good, heh? ;-) No way. Memory leaks are fun. ;-) 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
Toby Dickenson wrote: On Tue, 12 Mar 2002 18:38:16 +0100, Oliver Bleutgen [EMAIL PROTECTED] wrote: Acquisition.ImplicitAcquirerWrapper: 42442 That class is used to glue together acquisition content chains. Being top of the list indicates that you have been leaking an acquisition context chain. That doesnt mean that the bug relates to acquisition; acquisition just means that the leak is more severe than otherwise (because it keeps the whole context chain around). OFS.DTMLMethod.DTMLMethod: 3989 42442/3989 = 10.6. That indicates that you are leaking an acquisition chain of roughly 10 objects. ZPublisher.HTTPRequest.HTTPRequest: 3941 ZServer.HTTPResponse.ZServerHTTPResponse: 3934 ZPublisher.BaseRequest.RequestContainer: 3931 AccessControl.DTML.TemplateDict: 3930 The numbers for those objects are all roughly 3900. These objects are the ones referenced by that acquisition chain. I recommend you look further down that list, until you find a number that is much less than 3900. All of the objects above that mark are pieces of the jigsaw puzzle that will tell you *what* is being leaked. Thats where I would start meditating to work out *how* its being leaked. Ah, thanks for the nice explanation, Toby. I don't want to abuse your or others time too much, but since this might be interesting in general too, I'll give some more data. To be clear, I don't want to really trace down that leak, we live with it for nearly a year now, the server will be replaced soon, but I'm smelling some zen and my appetite is whet. - I did paste only the objects which have such a high count (next one was approx 200). - This server (2.3.3) has no special products on it, just 2 Folderish ZClasses, which are heavily used (they construct the whole site). So, can we rule out that there's a bug in the zclasses machinery which is the cause for this? I.e. should there be some zclass related object in the above list otherwise? Is it right that in Zope 2.3.x (and others?) usage of dtml-var REQUEST.set(...) can lead to such leakage? Is there a description somewhere what the basic causes of such leakages are? I.e. only bugs in python c-code/zope c-code? Is there some text about what to not do in python product development to avoid introducing leakage? For example, on #zope someone pointed out to me that storing acquisition wrappers in the ZODB will lead to leakage. cheers, oliver ___ 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
On Wed, 13 Mar 2002 11:37:00 +0100, Oliver Bleutgen [EMAIL PROTECTED] wrote: - I did paste only the objects which have such a high count (next one was approx 200). Hmm. Ill have to ponder what that means. - This server (2.3.3) has no special products on it, just 2 Folderish ZClasses, which are heavily used (they construct the whole site). So, can we rule out that there's a bug in the zclasses machinery which is the cause for this? No, thats not impossible I.e. should there be some zclass related object in the above list otherwise? Not necessarily. The class with the bug need not leave an instance of himself tied up in his immortal cyclic trash. Is it right that in Zope 2.3.x (and others?) usage of dtml-var REQUEST.set(...) can lead to such leakage? Yes, thats true in all versions. Is there a description somewhere what the basic causes of such leakages are? I.e. only bugs in python c-code/zope c-code? No, its possible for a bug in through-the-web edited dtml to cause this. Is there some text about what to not do in python product development to avoid introducing leakage? For example, on #zope someone pointed out to me that storing acquisition wrappers in the ZODB will lead to leakage. In old versions (roughly before 2.3 or 2.4; I forget exactly when) it was possible to create a cyles involving a persistent object having a reference to an acquisition wrapper. Today that raises an exception. 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] more on the segfault saga
On Tuesday, March 12, 2002, at 05:08 PM, Leonardo Rochael Almeida wrote: Matthew, thanks for taking the time to gdb the beast with me. Did you come up with any instrumentation I should add to Python or Zope to get what it is that Python is trying to resease twice? If you want, I can arrange a MySQL-less period during production so that we can capture the crash in a cleaner environment. Sorry, I only dug out what I had and made THAT work; it was a single-thread profiler. It will require some modding to turn it into a useful debug tool instead, and I've been busy with other things. Speaking of instrumentation, since the gremlin seems to be threading related (it stops with '-t 1'), it might be useful to serialize certain parts of the execution path with semaphors, like the path to the restoration or the execution of PythonScripts, the path to the execution of SQL queries, etc. this means running with small locks in certain sections instead of the big '-t 1' lock (which is not really a lock, but you get the picture :-). Well, if you have the energy to try serializing some of of the base parts of the code, by all means, go ahead. I can't even begin to guess where the problem is though. ___ 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
Andre Schubert schrieb: Andy McKay schrieb: Didnt Shane do a leak finder product that can help debug this? http://www.zope.org/Members/hathawsh I will install the LeakFinder product on the server and look what happens If have installed LeakFinder this morning and restarted zope. My processes are grown up from 48MB to 78MB in about 4 hours, it never was so much ( the last time 10MB per week! ) In this time i got the following top 10 refcounts from leakfinder. OFS.Image.Image 36319 DocumentTemplate.DT_Util.Eval 9802 DateTime.DateTime.DateTime 6539 OFS.DTMLDocument.DTMLDocument 5454 OFS.Folder.Folder 5386 OFS.DTMLMethod.DTMLMethod 4850 DocumentTemplate.DT_In.InClass 1725 Products.ZSQLMethods.SQL.SQL 996 Products.TransparentFolders.TransparentFolder.TransparentFolder 458 DocumentTemplate.DT_Let.Let 398 Hope this list helps ... Thanks On March 12, 2002 08:42 am, Chris McDonough wrote: Finding memory leaks is an exercise in binary search. Isolate half of the Zope (and Product) code and find out if it leaks. If it doesn't, you know the problem is in the other half. ;-) Ad infinitum. I'm sorry this is the case, but it almost always boils down to this particular recipe of diagnostics. -- Andy McKay ___ 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 ) -- 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 ) -- 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] Re: more on the segfault saga
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 [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
One more question then I'll shut up ;-). Toby Dickenson wrote: Is there a description somewhere what the basic causes of such leakages are? I.e. only bugs in python c-code/zope c-code? No, its possible for a bug in through-the-web edited dtml to cause this. Waah, this is the first time I hear that. That means that even if zope/python would be bug-free, it's possible to write dtml that causes a leak? Is there a (non-esoteric) example for that? cheers, oliver ___ 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
On Wed, 13 Mar 2002 13:46:27 +0100, Oliver Bleutgen [EMAIL PROTECTED]
wrote:
Waah, this is the first time I hear that. That means that even if
zope/python would be bug-free, it's possible to write dtml that causes a
leak?
Is there a (non-esoteric) example for that?
(untested, but the principal is sound)
dtml-call REQUEST.set('foo',x)
where x is some object whose acquisition context includes the REQUEST
object
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
The On Wed, 2002-03-13 at 10:05, Martijn Jacobs wrote: [...] 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. Actually, at least in Linux, with a recent gdb, you can attach gdb to zope in multithread mode. Just take the -t 1 from the command line sugested by the StabilityHOWTO and you're set. Best results are achieved by compiling everything from source (python even, use the --prefix=/path/to/zope-src so as not to mix up with your installed python and be careful to use this python when installing zope) and running: $ VARIABLE=value gdb path/to/your/python (gdb) run z2.py -Z '' where VARIABLE=value should be replaced by the env vars that are set in the ./start script inside Zope. Is this problem solved if I install python 2.2 for example? Are there any bugfixes in this release from Python 2.1.2 ? No, as far as I know. 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? I don't know about Zope Corp. in general, but Matt Kromer has been trying to help as much as his time permits. I think you're helping a lot just by reporting this problem because it helps raise awarenes to the fact that the stability problems aren't all solved with the last Zope/Python releases. So far there are three confirmed cases of instability: yours, mine and Dario's. All of them seem to involve PythonScripts, although this might not be related, and all of them are solved by using '-t 1' (is that correct, Dario?) so it looks like a threading issue. Let's just hope ZC or someone else in the community with more knowledge of the Zope/Python internal arcana can help us debug this, 'cause it's reached the limit of our exploration capability. Cheers, Leo ___ 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
On Wed, 2002-03-13 at 09:09, Matthew T. Kromer wrote: On Tuesday, March 12, 2002, at 05:08 PM, Leonardo Rochael Almeida wrote: Matthew, thanks for taking the time to gdb the beast with me. Did you come up with any instrumentation I should add to Python or Zope to get what it is that Python is trying to resease twice? If you want, I can arrange a MySQL-less period during production so that we can capture the crash in a cleaner environment. Sorry, I only dug out what I had and made THAT work; it was a single-thread profiler. It will require some modding to turn it into a useful debug tool instead, and I've been busy with other things. 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? Speaking of instrumentation, since the gremlin seems to be threading related (it stops with '-t 1'), it might be useful to serialize certain parts of the execution path with semaphors [...] Well, if you have the energy to try serializing some of of the base parts of the code, by all means, go ahead. I can't even begin to guess where the problem is though. Well, I have the energy, I just don't know where to start. But it's beginning to look like I'll just have to roll up my sleeves and dive in C code to hunt this beast down. And to think that I'd chosen Python as my official programming language to avoid just that... :-) -- 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 )
[Zope-dev] where is Zope 2.5.1?
I'm curious as to what is holding up Zope 2.5.1? 2.5.1b1 has been out for quite a while now (in Zope time). --andy. ___ 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
Leonardo Rochael Almeida wrote: Well, I have the energy, I just don't know where to start. But it's beginning to look like I'll just have to roll up my sleeves and dive in C code to hunt this beast down. And to think that I'd chosen Python as my official programming language to avoid just that... :-) I just found out about something that might help. If you compiled against the GNU C library, you can set the environment variable MALLOC_CHECK_ to 1 to get malloc usage warnings printed to stderr, or set it to 2 to cause an abort() as soon as an error is detected. Assuming you're running in production, I'd start with 1 (making sure stderr is connected to something), then if any warnings occur but they aren't informative enough, switch to 2. I learned this here: http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_32.html Shane ___ 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?
On Wed, 2002-03-13 at 13:03, Brian Lloyd wrote: We are trying to get to the bottom of a few straggling instability reports, so we're planning to go ahead with a b2 as soon as we've either a) figured out and fixed them b) figured them out and found it wasn't a Zope core problem or c) decide that we can't make enough progress in a reasonable time to continue holding up the release. Is there anything that we with unstable Zopes can do to help? -- 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] Re: more on the segfault saga
Actually, at least in Linux, with a recent gdb, you can attach gdb to zope in multithread mode. Just take the -t 1 from the command line sugested by the StabilityHOWTO and you're set. Best results are achieved by compiling everything from source (python even, use the --prefix=/path/to/zope-src so as not to mix up with your installed python and be careful to use this python when installing zope) and running: Ok, I succeeded tying up the gdb on the production server. I have to wait until tomorrow for results, because in the evening the intranet is not used by the specific company :) Tomorrow it will crash for sure, because it crashes about 20/30 times a day, so then I will post the results as soon as possible! It's very frustrating that we cannot reproduce this bug in out own environment, whatever we try. (all workstations requesting like hell, but we cannot succeed crashing it!) It's very nice to hear that you people are trying to solve the problem, also thanks to the guys from Zope Corp. who are spending there time for it! Hope the bug will be resolved soon. kind regards, martijn jacobs ___ 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] Help with DTML-IN statement
Hello, I am very new to Zope/DTML and I am a little confused with the operation of the DTML-IN statement. Here is the snippet of code table border=1 width=100%dtml-in expr="( ((1), (1,2),(4,5,6),(7,8,9)) )" tr tddtml-var sequence-item/td /tr/dtml-in/table This code displays the contents 4 cells in a table and the output is12(4,5,6)(7,8,9)I am a litte confused because I thought it would display the contents of the list as(1)(1,2)(4,5,6)(7,8,9)I believe this is related to something I read about tuples of ( key, value) will handled with sequence-key and sequence-item I must be traversing the list incorrectly.can anyone give me an example of how to traverse this list of tuples correctly. Any help would be greatly appreciated.thank you very much in advance Gary
RE: [Zope-dev] where is Zope 2.5.1?
On Wed, 2002-03-13 at 14:04, Brian Lloyd wrote: The best way to help is to help get this (these) down to a minimal, reproducable test case. 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. Getting there can be tricky, but there are some things that we can try to find out: - In the logs, is there any pattern to what is being accessed at the time of the crash? If there is a particular object or objects that seems to often be the last accessed before a crash, we can start looking at what PythonScripts the object uses. No, crashes happen all over the map (most of the site runs the same python scripts for authentication and inside ZClass instances) - Use the big M log to try to narrow down exactly what is happening at the time of the crash. Will do, but since the crashes happen all over the map, I don't think we'll be able to get much out of it - Ensure that you are getting absolutely no python scripts need to be recompiled messages Check! - Absolutely eliminate SQL db access as a cause (it sounds like we have proof of this now) Check! As someone else mentioned on this list, maybe if we could force the gc to collect alligned with the requests (say, in the first phase of the two-phase-commit transaction engine, or after the second phase) we could get the crashes to be reproduceable, or at least more localized. Also, as I pointed out before, since '-t 1' solves the crashes, if we could incrementally reduce the contention area around the code, by putting and successively removing locks around certain sections, we might be able to track it down. The problem is, I don't know enough about Zope code to know how to do any of those things, and I suspect the other folks with crashes are in the same situation. Cheers, Leo -- 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] Help with DTML-IN statement
Hi Gary, This question is more suited to [EMAIL PROTECTED] instead of [EMAIL PROTECTED], and you should not send html e-mail to any of these two lists, but since we are here... On Wed, 2002-03-13 at 16:13, Gary Yee wrote: Hello, I am very new to Zope/DTML and I am a little confused with the operation of the DTML-IN statement. Here is the snippet of code table border=1 width=100% dtml-in expr=( ((1), (1,2),(4,5,6),(7,8,9)) ) tr tddtml-var sequence-item/td /tr /dtml-in /table This code displays the contents 4 cells in a table and the output is 1 2 (4,5,6) (7,8,9) I am a litte confused because I thought it would display the contents of the list as (1) (1,2) (4,5,6) (7,8,9) I believe this is related to something I read about tuples of ( key, value) will handled with sequence-key and sequence-item That's exactly what's happening. It's a misfeature in my opinion, but it makes it easy to iterate thru a dictionary .items() and a folder .objectItems(). I must be traversing the list incorrectly. No, you're not, the feature is wrong :-) can anyone give me an example of how to traverse this list of tuples correctly. The workaround is to make each tuple of your sequence the second elemento of a 2-tuple, as in '((1, (1,)), (2, (1, 2)), (3, (4, 5, 6)), (4, (4, 5, 6)))' Kind of like that old joke were the paranoid statician would take a bomb with himself to the plane because the odds of there being two bombs on a plane were so low... -- 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
I set MALLOC_CHECK_ to 1 and it said it was using the malloc debug hooks, but didn't report anything else before the crashes, so no point in setting it to 2... On Wed, 2002-03-13 at 13:49, Shane Hathaway wrote: Leonardo Rochael Almeida wrote: On Wed, 2002-03-13 at 13:04, Shane Hathaway wrote: I just found out about something that might help. If you compiled against the GNU C library, you can set the environment variable MALLOC_CHECK_ to 1 to get malloc usage warnings printed to stderr, or set it to 2 to cause an abort() as soon as an error is detected. Assuming you're running in production, I'd start with 1 (making sure stderr is connected to something), then if any warnings occur but they aren't informative enough, switch to 2. I learned this here: http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_32.html Thanks Shane, I'll try that. But first I need a way to not supply -D and still get the stderr redirected. This site uses cookie authentication (exUserFolder) and even though the traceback ends up in a page that is shortly redirected from, some of our client's customers can spot it sometimes and they usually call complaining about the Zope error they saw imediatelly before the login page so we had to disable '-D'. -D is actually not related AFAIK. The C library will output to stderr regardless of whether -D is supplied, which means you need to use standard redirection anyway, for example: ./start /var/local/log/zope_output 21 -- 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] where is Zope 2.5.1?
On Wed, 2002-03-13 at 12:04, Brian Lloyd wrote: - Absolutely eliminate SQL db access as a cause (it sounds like we have proof of this now) This sounds like it is not specific to any DA. Is that the case? -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. ___ 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?
- Absolutely eliminate SQL db access as a cause (it sounds like we have proof of this now) This sounds like it is not specific to any DA. Is that the case? The only one I know of is the MySQL DA, but what I was getting at here was that eliminating ANY sql db access lets us discard the possibility of a DA problem and focus on other possibilities (IOW, is this really in Zope, or is this related to use or misuse of database libraries, which can vary widely in their thread support (or lack thereof). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 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] more on the segfault saga
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... Well, what I'm thinking about doing is trying to patch the Py_DECREF macro to record the free objects in a table and mark the freed memory with a signal value. Good thing it doesn't involve writing anything to stderr (right?), otherwise if gc.DEBUG_LEAK is a flood I cannot even begin to imagine the flood of PyDECREF messages... If you can produce a patch, I'm more than willing to apply it. I'm worried about the python script aspects. It's frustrating, because I am not aware of anything in pythonscripts that should be thread-dependent. The way the bytecode versions of said PythonScripts are kept in memory, perhaps? Although that's not likely, since each thread keeps its own version of that, even when recompilation is needed, right? 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. Questions: If I call gc.disable() but run gc.collect() from time to time I get the same effect, right? In this case, where in the code would I put a call to gc.collect() to get it to happen after the second phase of the two phase commit? Another aproach: would it be possible to, from time to time, put zope in a state where it enqueue new connections instead of servicing them while waiting for the currently running requests to finnish, then run gc.collect(), then start servicing requests again? Cheers, Leo ___ 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 )
