Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
On Wed, Dec 19, 2001 at 05:24:58PM -0200, Leonardo Rochael Almeida wrote: > On Wed, 2001-12-19 at 13:34, Chris McDonough wrote: > > It would be good if someone who is experiencing random crashes could confirm > > that the the new compiler package fixes their problem. > > I might risk losing a few more points with my sysadmin to test it (Hi > daniduc :-) if there was an easily downloadable package with clear > instructions on how to apply it to Zope 2.4.3 (I don't feel like messing > with CVS for this), and if you tell me that it won't corrupt my Data.fs > or anything :-) You can download files from CVS as a tarball. Just go to http://cvs.zope.org/Zope/lib/python/RestrictedPython and use the link at the bottom. -- Martijn Pieters | Software Engineer mailto:[EMAIL PROTECTED] | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ - ___ 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] disabling gc does not necessarily hide memory corruption
It would be good if someone who is experiencing random crashes could confirm that the the new compiler package fixes their problem. - Original Message - From: "Brian Lloyd" <[EMAIL PROTECTED]> To: "Chris McDonough" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: "Anthony Baxter" <[EMAIL PROTECTED]>; "Zope Developers list" <[EMAIL PROTECTED]> Sent: Wednesday, December 19, 2001 9:35 AM Subject: RE: [Zope-dev] disabling gc does not necessarily hide memory corruption > > Oh, ok, sorry for the misreport. It sounds then as if we need to fix > > whatever is causing the memory corruption that GC trips over. I dont > > know that we have a real good handle on what this is. > > I'm pretty sure we do. The stack estimation problems cause > memory stomping, which happens to tend to be found much more > quickly with GC enabled. > > Zope 2.5 b3 will contain a fixed compiler package. > > > Brian Lloyd[EMAIL PROTECTED] > Software Engineer 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] disabling gc does not necessarily hide memory corruption
> Oh, ok, sorry for the misreport. It sounds then as if we need to fix > whatever is causing the memory corruption that GC trips over. I dont > know that we have a real good handle on what this is. I'm pretty sure we do. The stack estimation problems cause memory stomping, which happens to tend to be found much more quickly with GC enabled. Zope 2.5 b3 will contain a fixed compiler package. Brian Lloyd[EMAIL PROTECTED] Software Engineer 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] disabling gc does not necessarily hide memory corruption
On Wed, 19 Dec 2001 06:07:00 +1100, Anthony Baxter <[EMAIL PROTECTED]> wrote: >For me, I run the ZEO server without GC (because that stops the stomped >stack bug killing the ZEO server) Do you have reason to believe that this bug can affect the ZEO server? that would be very bad. 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] disabling gc does not necessarily hide memory corruption
Oh, ok, sorry for the misreport. It sounds then as if we need to fix whatever is causing the memory corruption that GC trips over. I dont know that we have a real good handle on what this is. Note that in the meantime, folks who turn off gc in order to work around the issue who are having leakage problems should probably consider the use of AutoLance, a product that will restart your Zope if memory consumption is too high: http://www.zope.org/Members/mcdonc/Products/AutoLance . It currently only works on Linux. > Actually, I don't think the leaks haven't been fixed in CVS. It would > be at best painful to try and get the compiler code to work without > cycle GC. I really don't want to have to do 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 )
Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
>>> Jeremy Hylton wrote > Actually, I don't think the leaks haven't been fixed in CVS. It would > be at best painful to try and get the compiler code to work without > cycle GC. I really don't want to have to do it. In that case, there should probably be a readme note or similar saying "if you're using pythonscripts, don't bother without cyclic GC". For me, I run the ZEO server without GC (because that stops the stomped stack bug killing the ZEO server), and the ZEO clients with GC (and just wear the restarts. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too 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 )
Re: [Zope-dev] disabling gc does not necessarily hide memory corruption
> "CM" == Chris McDonough <[EMAIL PROTECTED]> writes: CM> Ah ok... yeah, there were reportedly several leaks in the CM> compiler stuff that have been fixed in CVS. I imagine that's CM> what this is. Actually, I don't think the leaks haven't been fixed in CVS. It would be at best painful to try and get the compiler code to work without cycle GC. I really don't want to have to do 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] disabling gc does not necessarily hide memory corruption
It is no longer based on bytecodehacks, it uses Jeremy's compiler module. It did produce some (unintended) circrefs, but I think the version in CVS as well as the version that will ship with Python 2.2 has these taken out. Toby Dickenson wrote: > On Mon, 17 Dec 2001 23:13:54 -0500, Chris McDonough <[EMAIL PROTECTED]> > wrote: > > >>Ah ok... yeah, there were reportedly several leaks in the compiler stuff >>that have been fixed in CVS. I imagine that's what this is. >> > > Is the compiler still based on bytecodehacks? If so, I dont think this > is a bug > > As I understand it, that package is designed to leave cyclic garbage > around under the assumption that python's garbage collector will break > the cycles. Early versions of bytecodehacks broke the cycles manually, > at a great performance cost. > > > 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 ) > -- Chris McDonoughZope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones" ___ 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] disabling gc does not necessarily hide memory corruption
On Mon, 17 Dec 2001 23:13:54 -0500, Chris McDonough <[EMAIL PROTECTED]> wrote: >Ah ok... yeah, there were reportedly several leaks in the compiler stuff >that have been fixed in CVS. I imagine that's what this is. Is the compiler still based on bytecodehacks? If so, I dont think this is a bug As I understand it, that package is designed to leave cyclic garbage around under the assumption that python's garbage collector will break the cycles. Early versions of bytecodehacks broke the cycles manually, at a great performance cost. 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] disabling gc does not necessarily hide memory corruption
Ah ok... yeah, there were reportedly several leaks in the compiler stuff that have been fixed in CVS. I imagine that's what this is. Anthony Baxter wrote: Chris McDonough wrote >>This behavior is with the patches to the compiler package that were the >>genesis of this thread? >> > > No, prior to that. I posted something about it to zope-dev an age or six > ago - it seemed like the RestrictedPython compiler had mungo mungo numbers > of cycles, and we found we couldn't run a zeo client on a nogc python for > more than about an hour. > > ah - here's the message I sent: > > Date:Wed, 17 Oct 2001 18:10:27 +1000 > To: [EMAIL PROTECTED] > From:Anthony Baxter <[EMAIL PROTECTED]> > Subject: RestrictedPython under no-GC 2.1 seems to leak a hell of a lot. > > Running current Zope 2.4 CVS under python 2.1 built --without-cycle-gc, > I'm seeing an absolutely _enormous_ amount of leaked objects in > RestrictedPython. This is on one of our ZEO clients, after 45 minutes > of runtime. The deltas are after 5 minutes. > > RestrictedPython.compiler.transformer.Transformer 146527 163546 +17019 > RestrictedPython.compiler.visitor.ASTVisitor 55842 62333 +6491 > RestrictedPython.compiler.misc.Set 34827 38843 +4016 > RestrictedPython.compiler.pyassem.FlowGraph 19173 21413 +2240 > RestrictedPython.compiler.ast.Stmt 19174 21390 +2216 > RestrictedPython.compiler.pycodegen.CodeGenerator 18333 20486 +2153 > RestrictedPython.compiler.symbols.SymbolVisitor 15303 17096 +1793 > RestrictedPython.compiler.ast.Name 13917 15542 +1625 > RestrictedPython.compiler.ast.Const 14083 15691 +1608 > RestrictedPython.compiler.ast.CallFunc 13798 15405 +1607 > RestrictedPython.MutatingWalker.MutatingWalker 11968 13360 +1392 > RestrictedPython.compiler.ast.Return 11986 13371 +1385 > RestrictedPython.compiler.ast.Function 11986 13371 +1385 > RestrictedPython.RestrictionMutator.RestrictionMutator 11800 13166 +1366 > RestrictedPython.compiler.pycodegen.LocalNameFinder 11028 12322 +1294 > RestrictedPython.compiler.pyassem.Block 10226 11401 +1175 > RestrictedPython.compiler.pyassem.PyFlowGraph 9587 10707 +1120 > RestrictedPython.compiler.misc.Stack 9587 10703 +1116 > RestrictedPython.compiler.ast.Module 9590 10698 +1108 > RestrictedPython.compiler.ast.Global 5761 6433 +672 > RestrictedPython.compiler.ast.Assign 5761 6433 +672 > RestrictedPython.compiler.ast.AssName 5761 6433 +672 > > [] > > -- Chris McDonoughZope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones" ___ 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] disabling gc does not necessarily hide memory corruption
>>> Chris McDonough wrote > This behavior is with the patches to the compiler package that were the > genesis of this thread? No, prior to that. I posted something about it to zope-dev an age or six ago - it seemed like the RestrictedPython compiler had mungo mungo numbers of cycles, and we found we couldn't run a zeo client on a nogc python for more than about an hour. ah - here's the message I sent: Date:Wed, 17 Oct 2001 18:10:27 +1000 To: [EMAIL PROTECTED] From:Anthony Baxter <[EMAIL PROTECTED]> Subject: RestrictedPython under no-GC 2.1 seems to leak a hell of a lot. Running current Zope 2.4 CVS under python 2.1 built --without-cycle-gc, I'm seeing an absolutely _enormous_ amount of leaked objects in RestrictedPython. This is on one of our ZEO clients, after 45 minutes of runtime. The deltas are after 5 minutes. RestrictedPython.compiler.transformer.Transformer 146527 163546 +17019 RestrictedPython.compiler.visitor.ASTVisitor 55842 62333 +6491 RestrictedPython.compiler.misc.Set 34827 38843 +4016 RestrictedPython.compiler.pyassem.FlowGraph 19173 21413 +2240 RestrictedPython.compiler.ast.Stmt 19174 21390 +2216 RestrictedPython.compiler.pycodegen.CodeGenerator 18333 20486 +2153 RestrictedPython.compiler.symbols.SymbolVisitor 15303 17096 +1793 RestrictedPython.compiler.ast.Name 13917 15542 +1625 RestrictedPython.compiler.ast.Const 14083 15691 +1608 RestrictedPython.compiler.ast.CallFunc 13798 15405 +1607 RestrictedPython.MutatingWalker.MutatingWalker 11968 13360 +1392 RestrictedPython.compiler.ast.Return 11986 13371 +1385 RestrictedPython.compiler.ast.Function 11986 13371 +1385 RestrictedPython.RestrictionMutator.RestrictionMutator 11800 13166 +1366 RestrictedPython.compiler.pycodegen.LocalNameFinder 11028 12322 +1294 RestrictedPython.compiler.pyassem.Block 10226 11401 +1175 RestrictedPython.compiler.pyassem.PyFlowGraph 9587 10707 +1120 RestrictedPython.compiler.misc.Stack 9587 10703 +1116 RestrictedPython.compiler.ast.Module 9590 10698 +1108 RestrictedPython.compiler.ast.Global 5761 6433 +672 RestrictedPython.compiler.ast.Assign 5761 6433 +672 RestrictedPython.compiler.ast.AssName 5761 6433 +672 [] ___ 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] disabling gc does not necessarily hide memory corruption
Anthony, This behavior is with the patches to the compiler package that were the genesis of this thread? Anthony Baxter wrote: Leonardo Rochael Almeida wrote >>>From my mile-high look at the issues, it seems like the cycle-gc asks >>for an object where to look for for it's references (at least thats what >>the tp_traverse function looks like it does). So, if your tp_traverse >>sends the gc somewhere it shouldn't go (or if tp_traverse itself is not >>some C function pointer), you get a crash. >> > > When I look at it, I see the GC hitting an object with a null tp_type, and > a refcount of 1. This is monster bogus - but normally (non-GC) it would > just be ignored and sit there as a small memory leak. > > >>import gc >>gc.disable() >>also stops the SIG11 without the need of a python recompile, but I'll >>only be sure when the server gets office-hours-traffic tomorrow morning. >> > > I find that if I do this I get a vast vast number of RestrictedPython > cycles leaking (according to the manage_debug screen) and memory consumption > goes through the roof. > > ___ > 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 ) > -- Chris McDonoughZope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones" ___ 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] disabling gc does not necessarily hide memory corruption
>>> Leonardo Rochael Almeida wrote > >From my mile-high look at the issues, it seems like the cycle-gc asks > for an object where to look for for it's references (at least thats what > the tp_traverse function looks like it does). So, if your tp_traverse > sends the gc somewhere it shouldn't go (or if tp_traverse itself is not > some C function pointer), you get a crash. When I look at it, I see the GC hitting an object with a null tp_type, and a refcount of 1. This is monster bogus - but normally (non-GC) it would just be ignored and sit there as a small memory leak. > import gc > gc.disable() > also stops the SIG11 without the need of a python recompile, but I'll > only be sure when the server gets office-hours-traffic tomorrow morning. I find that if I do this I get a vast vast number of RestrictedPython cycles leaking (according to the manage_debug screen) and memory consumption goes through the roof. ___ 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] disabling gc does not necessarily hide memory corruption
On Mon, 2001-12-17 at 20:57, Jeremy Hylton wrote: > > "MTK" == Matthew T Kromer <[EMAIL PROTECTED]> writes: > > MTK> A side effect of shutting off the garbage collector is that you > MTK> can have some storage leaks. We're working on being able to > MTK> re-enable the garbage collector so that you don't exhaust > MTK> memory over time. > > Do you have any more idea about what shutting the garbage collector > off achieves? In practice, the garbage collector's most common effect > is to turn latent bugs into manifest bugs; a bug has trashed part of > memory and the garbage collector just happens to find it first. If > you turn GC off in these cases, you run a little longer, but you're > running with corrupted memory. Not if the problem you're facing is bad colaboration with the cycle-gc. As can be gleaned from discussions in this list, the nature of the changes in ExtensionClass.h and the problem report on sourceforge mentioned in another e-mail in this list, colaboration with the cycle-gc is an active duty for Python objects written in C (or their derivatives, such as ExtensionClass por PythonScripts), and if you colaborate wrongly with the cycle-gc you are garanteed to get a crash, and worse of all, in the most random moments possible, with no clue as to what caused it. >From my mile-high look at the issues, it seems like the cycle-gc asks for an object where to look for for it's references (at least thats what the tp_traverse function looks like it does). So, if your tp_traverse sends the gc somewhere it shouldn't go (or if tp_traverse itself is not some C function pointer), you get a crash. Of course I could be absolutely wrong in this description (you'd need to get a python guru for a correct one. Oh, wait, you guys got a bunch of those hanging around, right? :-)) but it is the only one I got :-) BTW, from my tests so far, it seems like: import gc gc.disable() also stops the SIG11 without the need of a python recompile, but I'll only be sure when the server gets office-hours-traffic tomorrow morning. Cheers, -- 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 )
