summaryrefslogtreecommitdiffstats
path: root/Modules/gcmodule.c
Commit message (Collapse)AuthorAgeFilesLines
* Fixed the gc-vs-__del__ bugs for new-style classes. That's it for this one.Tim Peters2003-04-081-10/+6
|
* More backporting of gc-vs-__del__ fixes. It should be fixed for instancesTim Peters2003-04-081-5/+17
| | | | | | of classic classes now. Alas, new-style classes are still a problem, and didn't need to be fixed in 2.3 (they were already immune in 2.3 due to the new-in-2.3 tp_del slot).
* Fix memory corruption in garbage collection.Jeremy Hylton2003-04-031-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The move_finalizers() routine checks each object in the unreachable list to see if it has a finalizer. If it does, it is moved to the finalizers list. The collector checks by calling, effectively, hasattr(obj, "__del__"). The hasattr() call can result in an arbitrary amount of Python code being run, because it will invoke getattr hooks on obj. If a getattr() hook is run from move_finalizers(), it may end up resurrecting or deallocating objects in the unreachable list. In fact, it's possible that the hook causes the next object in the list to be deallocated. That is, the object pointed to by gc->gc.gc_next may be freed before has_finalizer() returns. The problem with the previous revision is that it followed gc->gc.gc_next before calling has_finalizer(). If has_finalizer() gc->happened to deallocate the object FROM_GC(gc->gc.gc_next), then the next time through the loop gc would point to freed memory. The fix is to always follow the next pointer after calling has_finalizer(). Note that Python 2.3 does not have this problem, because has_finalizer() checks the tp_del slot and never runs Python code. Tim, Barry, and I peed away the better part of two days tracking this down.
* Backport for SF bug #574132: Major GC related performance regression.Tim Peters2002-06-301-13/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2.2.1 has another bug that prevents the regression (which isn't a regression at all) from showing up. "The regression" is actually a glitch in cyclic gc that's been there forever. As the generation being collected is analyzed, objects that can't be collected (because, e.g., we find they're externally referenced, or are in an unreachable cycle but have a __del__ method) are moved out of the list of candidates. A tricksy scheme uses negative values of gc_refs to mark such objects as being moved. However, the exact negative value set at the start may become "more negative" over time for objects not in the generation being collected, and the scheme was checking for an exact match on the negative value originally assigned. As a result, objects in generations older than the one being collected could get scanned too, and yanked back into a younger generation. Doing so doesn't lead to an error, but doesn't do any good, and can burn an unbounded amount of time doing useless work. A test case is simple (thanks to Kevin Jacobs for finding it!): x = [] for i in xrange(200000): x.append((1,)) Without the patch, this ends up scanning all of x on every gen0 collection, scans all of x twice on every gen1 collection, and x gets yanked back into gen1 on every gen0 collection. With the patch, once x gets to gen2, it's never scanned again until another gen2 collection, and stays in gen2. Opened another bug about that 2.2.1 isn't actually tracking (at least) iterators, generators, and bound method objects, due to using the 2.1 gc API internally in those places (which #defines itself out of existence in 2.2.x).
* backport tim_one's patch:Anthony Baxter2002-04-301-2/+6
| | | | | | | | | | | | | (some tweaking for different _PyObject_GC_Malloc() call in 2.2. checked, still returns the same thing on failure...) _PyObject_GC_New: Could call PyObject_INIT with a NULL 1st argument. _PyObject_GC_NewVar: Could call PyObject_INIT_VAR likewise. Bugfix candidate. Original patch(es): python/dist/src/Modules/gcmodule.c:2.40
* The body of_PyObject_GC_UnTrack() should only be compiled #ifdefGuido van Rossum2002-04-031-0/+2
| | | | | WITH_CYCLE_GC. (Neil pointed this out before the weekend, and I fixed it right away, but forgot to check it in.)
* Backport to 2.2.1:Guido van Rossum2002-03-281-1/+3
| | | | | | | | | | This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction). The fix makes it possible to call PyObject_GC_UnTrack() more than once on the same object, and then move the PyObject_GC_UnTrack() call to *before* the trashcan code is invoked. BUGFIX CANDIDATE!
* Fix a bunch of typos found by nnorwitz.Michael W. Hudson2002-02-061-1/+1
|
* Check for NULL return value of PyList_New (follow-up to patch #486743).Martin v. Löwis2001-12-021-0/+3
|
* Patch #486743: remove bad INCREF, propagate exception in append_objects.Martin v. Löwis2001-12-021-6/+11
|
* Use identity instead of equality when looking for referrers. Fixes #485781.Martin v. Löwis2001-11-291-3/+4
|
* Rename get_referents to get_referrers. Fixes #483815.Martin v. Löwis2001-11-241-12/+12
|
* has_finalizer(): simplified "if (complicated_bool) 1 else 0" toTim Peters2001-11-011-8/+3
| | | | "complicated_bool".
* Add has_finalizer predictate function. Use it when deciding whichNeil Schemenauer2001-11-011-14/+26
| | | | | | | | | | | objects to save in gc.garbage. This should be the last change needed to fix SF bug 477059: "__del__ on new classes vs. GC". Note that this change slightly changes the behavior of the collector. Before, if a cycle was found that contained instances with __del__ methods then all instance objects in that cycle were saved in gc.garbage. Now, only objects with __del__ methods are saved in gc.garbage.
* SF bug #477059 (my own): __del__ on new classes vs. GC.Guido van Rossum2001-11-011-1/+3
| | | | | | When moving objects with a __del__ attribute to a special list, look for __del__ on new-style classes with the HEAPTYPE flag set as well. (HEAPTYPE means the class was created by a class statement.)
* Make the gc.collect() function respect the collection lock. This fixesNeil Schemenauer2001-10-311-4/+11
| | | | SF bug 476129: "gc.collect sometimes hangs".
* Use double curly braces for the generation0/1/2 initializers, to shutGuido van Rossum2001-10-121-3/+3
| | | | up GCC warnings.
* SF bug [#467145] Python 2.2a4 build problem on HPUX 11.0.Tim Peters2001-10-111-56/+56
| | | | | | | | | | | | | | The platform requires 8-byte alignment for doubles, but the GC header was 12 bytes and that threw off the natural alignment of the double members of a subtype of complex. The fix puts the GC header into a union with a double as the other member, to force no-looser-than double alignment of GC headers. On boxes that require 8-byte alignment for doubles, this may add pad bytes to the GC header accordingly; ditto for platforms that *prefer* 8-byte alignment for doubles. On platforms that don't care, it shouldn't change the memory layout (because the size of the old GC header is certainly greater than the size of a double on all platforms, so unioning with a double shouldn't change size or alignment on such boxes).
* Guido suggests, and I agree, to insist that SIZEOF_VOID_P be a power of 2.Tim Peters2001-10-071-12/+4
| | | | | | This simplifies the rounding in _PyObject_VAR_SIZE, allows to restore the pre-rounding calling sequence, and allows some nice little simplifications in its callers. I'm still making it return a size_t, though.
* _PyObject_VAR_SIZE: always round up to a multiple-of-pointer-size value.Tim Peters2001-10-061-14/+21
| | | | | | | | | | | | | | | | | As Guido suggested, this makes the new subclassing code substantially simpler. But the mechanics of doing it w/ C macro semantics are a mess, and _PyObject_VAR_SIZE has a new calling sequence now. Question: The PyObject_NEW_VAR macro appears to be part of the public API. Regardless of what it expands to, the notion that it has to round up the memory it allocates is new, and extensions containing the old PyObject_NEW_VAR macro expansion (which was embedded in the PyObject_NEW_VAR expansion) won't do this rounding. But the rounding isn't actually *needed* except for new-style instances with dict pointers after a variable-length blob of embedded data. So my guess is that we do not need to bump the API version for this (as the rounding isn't needed for anything an extension can do unless it's recompiled anyway). What's your guess?
* Repaired the debug Windows deaths in test_descr, by allocating enoughTim Peters2001-10-061-7/+8
| | | | | | | | | | | | | | pad memory to properly align the __dict__ pointer in all cases. gcmodule.c/objimpl.h, _PyObject_GC_Malloc: + Added a "padding" argument so that this flavor of malloc can allocate enough bytes for alignment padding (it can't know this is needed, but its callers do). typeobject.c, PyType_GenericAlloc: + Allocated enough bytes to align the __dict__ pointer. + Sped and simplified the round-up-to-PTRSIZE logic. + Added blank lines so I could parse the if/else blocks <0.7 wink>.
* _PyObject_GC_Malloc(): split a complicated line in two. As is, there wasTim Peters2001-10-061-2/+3
| | | | | no way to talk the debugger into showing me how many bytes were being allocated.
* Make more things internal to this file. RemoveNeil Schemenauer2001-08-301-93/+148
| | | | | | | | | visit_finalizer_reachable since it's the same as visit_reachable. Rename visit_reachable to visit_move. Objects can now have the GC type flag set, reachable by tp_traverse and not be in a GC linked list. This should make the collector more robust and easier to use by extension module writers. Add memory management functions for container objects (new, del, resize).
* Remove "referents" structure (it's not needed). Check return valueNeil Schemenauer2001-08-101-20/+17
| | | | of PyList_Append.
* Add get_objects function. This is a low level function (likeNeil Schemenauer2001-08-091-0/+38
| | | | | get_referents, and is not yet documented in the library manual). Suggestions for a better name welcome.
* Add get_referents function. Closes SF patch #402925.Neil Schemenauer2001-08-091-0/+50
|
* - update Neil's email addressNeil Schemenauer2000-10-041-6/+2
|
* - do not start collection during processing of an exceptionNeil Schemenauer2000-10-041-1/+5
|
* Fix some long/"l" int/"i" mismatches. Fixes bug #113779.Neil Schemenauer2000-09-221-2/+2
|
* - Add DEBUG_SAVEALL option. When enabled all garbage objects found by theNeil Schemenauer2000-09-221-27/+39
| | | | | | | collector will be saved in gc.garbage. This is useful for debugging a program that creates reference cycles. - Fix else statements in gcmodule.c to conform to Python coding standards.
* compromise value for threshold0: not too high, not too lowJeremy Hylton2000-09-051-1/+1
|
* set the default threshold much higherJeremy Hylton2000-09-011-1/+1
| | | | we don't need to run gc frequently
* refactor __del__ exception handler into PyErr_WriteUnraisableJeremy Hylton2000-09-011-1/+10
| | | | | add sanity check to gc: if an exception occurs during GC, call PyErr_WriteUnraisable and then call Py_FatalEror.
* apply patch #101362 by Vladimir MarangozovJeremy Hylton2000-08-311-33/+24
| | | | also initial static debug variable to 0
* Neil Schemenauer: GC enable(), disable(), isenabled() interface.Vladimir Marangozov2000-08-061-16/+76
| | | | | | Small stylistic changes by VM: - is_enabled() -> isenabled() - static ... Py_<func> -> static ... gc_<func>
* debug_instance(): Use the same %p format directive as withBarry Warsaw2000-07-121-6/+3
| | | | | | debug_cycle(), and don't cast the pointer to a long. Neither needs the literal `0x' prefix as %p automatically inserts this (on Linux at least).
* Always use the :funcname part of the format specifier for PyArg_ParseTuple()Fred Drake2000-07-121-5/+5
| | | | so we get better error messages.
* Neil Schemenauer <nascheme@enme.ucalgary.ca>:Fred Drake2000-07-111-4/+4
| | | | | | | Change a cast, intialize a local, and make some sprintf() format strings type-appropriate (add the "l" to "%d"). Closes SourceForge patch #100737.
* ANSI-ficationPeter Schneider-Kamp2000-07-101-15/+5
|
* Initialize the return value in collect_generations() since it is updatedVladimir Marangozov2000-07-101-1/+1
| | | | conditionally in the code.
* final patches from Neil Schemenauer for garbage collectionJeremy Hylton2000-06-301-0/+679
generated by cgit v0.12 at 2025-12-26 19:27:24 (GMT)