[Zope-dev] disabling gc does not necessarily hide memory corruption

Leonardo Rochael Almeida leo@hiper.com.br
17 Dec 2001 23:02:01 -0200


On Mon, 2001-12-17 at 20:57, Jeremy Hylton wrote:
> >>>>> "MTK" == Matthew T Kromer <matt@zope.com> 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.