Barry Warsaw: > When I compile out gc, I get more leaks in the core, namely in > exceptions.c. Turning on gc clears all of these up; e.g. all the > memory gets freed eventually. My suspicion therefore is that there > are a number of cycles created during the initialization of the > built-in exceptions. Vladimir Marangozov: > I think that if we start relaxing our attention w.r.t. refcount policies, > cyclic refs and the resulting mem leaks _in_the_core_, just because gc > helps in hiding bad practice, we'll suffer more than you would in the > attempt to fix these things. Let me explain something about the new GC code. It does *not* hide missed DECREFs. If you miss a DECREF, the GC code thinks there's a global pointer to the object that keeps it alive, and will not release the object. I don't know what Barry found, but I suspect they are genuine cycles created during the exception initialization. It's easy enough to create cycles, e.g. form module -> class -> function -> module, or module -> function -> module, when defining classes or functions. The new GC code is *intended* to clean up exactly such cycles! --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4