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
CTED]>
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 so
> 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 ten
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 Dickens
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 leaka
>>> 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
> "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 pain
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 McDo
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
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?
>>
>
>
>>> 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 foun
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 (
>>> 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 (o
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
14 matches
Mail list logo
