Commit Graph

99 Commits

Author SHA1 Message Date
Martin v. Löwis 6819210b9e PEP 3123: Provide forward compatibility with Python 3.0, while keeping
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
2007-07-21 06:55:02 +00:00
Barry Warsaw e5ec613c4b List gc.get_count() in the module docstring. 2006-10-09 19:43:24 +00:00
Georg Brandl 684fd0c8ec Replace PyObject_CallFunction calls with only object args
with PyObject_CallFunctionObjArgs, which is 30% faster.
2006-05-25 19:15:31 +00:00
Neal Norwitz 57a0361a9e Patch from Aldo Cortesi (OpenBSD buildbot owner).
After the patch (45590) to add extra debug stats to the gc module, Python
was crashing on OpenBSD due to:
	Fatal Python error: Interpreter not initialized (version mismatch?)

This seems to occur due to calling collect() when initialized (in pythonrun.c)
is set to 0.  Now, the import will occur in the init function which
shouldn't suffer this problem.
2006-04-26 05:34:03 +00:00
Skip Montanaro c34b931d78 This is a long-ago patch I submitted to SF (1100924) to time the gc passes.
Barry approved it awhile ago.  Been sitting in my sandbox for awhile as
well.
2006-04-21 01:33:40 +00:00
Anthony Baxter 64182fe0b3 Some more changes to make code compile under a C++ compiler. 2006-04-11 12:14:09 +00:00
Phillip J. Eby 2ba96610bf SF Patch #1463867: Improved generator finalization to allow generators
that are suspended outside of any try/except/finally blocks to be
garbage collected even if they are part of a cycle.  Generators that
suspend inside of an active try/except or try/finally block (including
those created by a ``with`` statement) are still not GC-able if they
are part of a cycle, however.
2006-04-10 17:51:05 +00:00
Neal Norwitz ffb0d90a6e Handle ssize_t 2006-04-06 08:07:25 +00:00
Tim Peters 62e97f023b In format strings slinging Py_ssize_t, unconditionally
interpolate PY_FORMAT_SIZE_T instead of #if'ing on
MS_WIN64.
2006-03-28 21:44:32 +00:00
Georg Brandl 5c170fd4a9 Fix some missing checks after PyTuple_New, PyList_New, PyDict_New 2006-03-17 19:03:25 +00:00
Barry Warsaw d3c38ff7f8 SF patch #1443865; gc.get_count() added and optional argument 'generation'
added to gc.collect().  Updated docs, unit test, and NEWS entry.

(Also, fixed a typo in NEWS.)
2006-03-07 09:46:03 +00:00
Neal Norwitz e22373d690 Fix warnings on x86 (32-bit) and support Win64. 2006-03-06 23:31:56 +00:00
Neal Norwitz 7b216c52e4 Make PyGC_Collect() use Py_ssize_t. 2006-03-04 20:01:53 +00:00
Martin v. Löwis 6db0e00d57 Change GC refcount to Py_ssize_t. 2006-03-01 16:56:25 +00:00
Martin v. Löwis 41290685f9 Change _PyObject_GC_Resize to expect Py_ssize_t. 2006-02-16 14:56:14 +00:00
Martin v. Löwis 18e165558b Merge ssize_t branch. 2006-02-15 17:27:45 +00:00
Neal Norwitz 1ac754fa10 Check return result from Py_InitModule*(). This API can fail.
Probably should be backported.
2006-01-19 06:09:39 +00:00
Phillip J. Eby 0d6615fd29 PEP 342 implementation. Per Guido's comments, the generator throw()
method still needs to support string exceptions, and allow None for the
third argument.  Documentation updates are needed, too.
2005-08-02 00:46:46 +00:00
Neil Schemenauer 3b1cbf9ba0 Add missing INCREF.
Backport candidate.
2005-06-18 17:37:06 +00:00
Tim Peters bc1d1b80d1 gc_list_move(): Make this truly equivalent to remove+append. While
nothing in gc currently cares, the original coding could screw up if,
e.g., you tried to move a node to the list it's already in, and the node
was already the last in its list.
2004-11-01 16:39:57 +00:00
Tim Peters e2d591847c gc list function cleanup.
Introduced gc_list_move(), which captures the common gc_list_remove() +
gc_list_append() sequence.  In fact, no uses of gc_list_append() remained
(they were all in a gc_list_move() sequence), so commented that one out.

gc_list_merge():  assert that `from` != `to`; that was an implicit
precondition, now verified in a debug build.

Others:  added comments about their purpose.
2004-11-01 01:39:08 +00:00
Tim Peters cc2a866cb7 handle_weakrefs(): Simplification -- there's no need to make a second
pass over the unreachable weakrefs-with-callbacks to unreachable objects.
2004-10-31 22:12:43 +00:00
Tim Peters ead8b7ab30 SF 1055820: weakref callback vs gc vs threads
In cyclic gc, clear weakrefs to unreachable objects before allowing any
Python code (weakref callbacks or __del__ methods) to run.

This is a critical bugfix, affecting all versions of Python since weakrefs
were introduced.  I'll backport to 2.3.
2004-10-30 23:09:22 +00:00
Raymond Hettinger 674d56b82e Convert return value to boolean. 2004-01-04 04:00:13 +00:00
Guido van Rossum 0bba722fff Silence GCC warning when asserts are turned off. 2003-11-24 04:02:13 +00:00
Tim Peters 403a203223 SF bug 839548: Bug in type's GC handling causes segfaults.
Also SF patch 843455.

This is a critical bugfix.
I'll backport to 2.3 maint, but not beyond that.  The bugs this fixes
have been there since weakrefs were introduced.
2003-11-20 21:21:46 +00:00
Tim Peters 780c497972 update_refs(): assert that incoming refcounts aren't 0. The comment
for this function has always claimed that was true, but it wasn't
verified before.  For the latest batch of "double deallocation" bugs
(stemming from weakref callbacks invoked by way of subtype_dealloc),
this assert would have triggered (instead of waiting for
_Py_ForgetReference to die with a segfault later).
2003-11-14 00:01:17 +00:00
Jason Tishler 6bc06eca70 Bug #794140: cygwin builds do not embed
The embed2.diff patch solves the user's problem by exporting the missing
symbols from the Python core so Python can be embedded in another Cygwin
application (well, at lest vim).
2003-09-04 11:59:50 +00:00
Guido van Rossum e13ddc9ec8 - New C API PyGC_Collect(), same as calling gc.collect().
- Call this in Py_Finalize().
- Expand the Misc/NEWS text on PY_LONG_LONG.
2003-04-17 17:29:22 +00:00
Tim Peters 730f5535ba s/referrents/referents/g. Gotta love that referrers remains rife with rs. 2003-04-08 17:17:17 +00:00
Tim Peters 0f81ab6d88 Finished implementing gc.get_referrents(): dealt with error and end
cases, wrote docs, added a test.
2003-04-08 16:39:48 +00:00
Tim Peters fb2ab4d5ae Comment repair; no semantic changes. 2003-04-07 22:41:24 +00:00
Tim Peters f6b8045ca5 Reworked has_finalizer() to use the new _PyObject_Lookup() instead
of PyObject_HasAttr(); the former promises never to execute
arbitrary Python code.  Undid many of the changes recently made to
worm around the worst consequences of that PyObject_HasAttr() could
execute arbitrary Python code.

Compatibility is hard to discuss, because the dangerous cases are
so perverse, and much of this appears to rely on implementation
accidents.

To start with, using hasattr() to check for __del__ wasn't only
dangerous, in some cases it was wrong:  if an instance of an old-
style class didn't have "__del__" in its instance dict or in any
base class dict, but a getattr hook said __del__ existed, then
hasattr() said "yes, this object has a __del__".  But
instance_dealloc() ignores the possibility of getattr hooks when
looking for a __del__, so while object.__del__ succeeds, no
__del__ method is called when the object is deleted.  gc was
therefore incorrect in believing that the object had a finalizer.

The new method doesn't suffer that problem (like instance_dealloc(),
_PyObject_Lookup() doesn't believe __del__ exists in that case), but
does suffer a somewhat opposite-- and even more obscure --oddity:
if an instance of an old-style class doesn't have "__del__" in its
instance dict, and a base class does have "__del__" in its dict,
and the first base class with a "__del__" associates it with a
descriptor (an object with a __get__ method), *and* if that
descriptor raises an exception when __get__ is called, then
(a) the current method believes the instance does have a __del__,
but (b) hasattr() does not believe the instance has a __del__.

While these disagree, I believe the new method is "more correct":
because the descriptor *will* be called when the object is
destructed, it can execute arbitrary Python code at the time the
object is destructed, and that's really what gc means by "has a
finalizer":  not specifically a __del__ method, but more generally
the possibility of executing arbitrary Python code at object
destruction time.  Code in a descriptor's __get__() executed at
destruction time can be just as problematic as code in a
__del__() executed then.

So I believe the new method is better on all counts.

Bugfix candidate, but it's unclear to me how all this differs in
the 2.2 branch (e.g., new-style and old-style classes already
took different gc paths in 2.3 before this last round of patches,
but don't in the 2.2 branch).
2003-04-07 19:21:15 +00:00
Tim Peters 1155887a74 initgc(): Rewrote to use the PyModule_AddXYZ API; cuts code size. 2003-04-06 23:30:52 +00:00
Tim Peters 259272b7a0 handle_finalizers(): Rewrote to call append_objects() and gc_list_merge()
instead of looping.  Smaller and clearer.  Faster, too, when we're not
appending to gc.garbage:  gc_list_merge() takes constant time, regardless
of the lists' sizes.

append_objects():  Moved up to live with the other list manipulation
utilities.
2003-04-06 19:41:39 +00:00
Tim Peters 50c61d5a6c Switched from METH_VARARGS to METH_NOARGS for the 7 module functions that
take no arguments; cuts generated code size.
2003-04-06 01:50:50 +00:00
Tim Peters bf384c256e Reworked move_finalizer_reachable() to create two distinct lists:
externally unreachable objects with finalizers, and externally unreachable
objects without finalizers reachable from such objects.  This allows us
to call has_finalizer() at most once per object, and so limit the pain of
nasty getattr hooks.  This fixes the failing "boom 2" example Jeremy
posted (a non-printing variant of which is now part of test_gc), via never
triggering the nasty part of its __getattr__ method.
2003-04-06 00:11:39 +00:00
Tim Peters f6ae7a43eb move_finalizers(): Rewrote. It's not necessary for this routine
to special-case classic classes, or to worry about refcounts;
has_finalizer() deleted the current object iff the first entry in
the unreachable list has changed.  I don't believe it was correct
to check for ob_refcnt == 1, either:  the dealloc routine would get
called by Py_DECREF then, but there's nothing to stop the dealloc
routine from ressurecting the object, and then gc would remain at
the head of the unreachable list despite that its refcount temporarily
fell to 0 (and that would lead to an infinite loop in move_finalizers()).

I'm still worried about has_finalizer() resurrecting other objects
in the unreachable list:  what's to stop them from getting collected?
2003-04-05 18:40:50 +00:00
Tim Peters 86b993b6cf New comments. Rewrote has_finalizer() as a sequence of ifs instead of
squashed-together conditional operators; makes it much easier to step
thru in the debugger, and to set a breakpoint on the only dangerous
path.
2003-04-05 17:35:54 +00:00
Tim Peters 93ad66dea9 Fixed new seemingly random segfaults, by moving the initialization of
delstr from initgc() into collect().  initgc() isn't called unless the
user explicitly imports gc, so can be used only for initialization of
user-visible module features; delstr needs to be initialized for proper
internal operation, whether or not gc is explicitly imported.

Bugfix candidate?  I don't know whether the new bug was backported to
2.2 already.
2003-04-05 17:15:44 +00:00
Jeremy Hylton ce136e985a Fix Tim's boom example.
move_finalizers() moves every object from unreachable to collectable
or finalizers, unless the object is deallocated first.
2003-04-04 19:59:06 +00:00
Jeremy Hylton 059b094e29 Add get_referrents() helper function. 2003-04-03 16:29:13 +00:00
Jeremy Hylton 5bd378bfca Add get_referrents() helper function. 2003-04-03 16:28:38 +00:00
Martin v. Löwis 774348c8d6 Fix typo. 2002-11-09 19:54:06 +00:00
Guido van Rossum 4030714a93 For new-style classes, we can now test for tp_del instead of asking
for a __del__ attribute, to see if there's a finalizer.
2002-08-09 17:39:14 +00:00
Tim Peters 803526b9e2 Trashcan cleanup: Now that cyclic gc is always there, the trashcan
mechanism is no longer evil:  it no longer plays dangerous games with
the type pointer or refcounts, and objects in extension modules can play
along too without needing to edit the core first.

Rewrote all the comments to explain this, and (I hope) give clear
guidance to extension authors who do want to play along.  Documented
all the functions.  Added more asserts (it may no longer be evil, but
it's still dangerous <0.9 wink>).  Rearranged the generated code to
make it clearer, and to tolerate either the presence or absence of a
semicolon after the macros.  Rewrote _PyTrash_destroy_chain() to call
tp_dealloc directly; it was doing a Py_DECREF again, and that has all
sorts of obscure distorting effects in non-release builds (Py_DECREF
was already called on the object!).  Removed Christian's little "embedded
change log" comments -- that's what checkin messages are for, and since
it was impossible to correlate the comments with the code that changed,
I found them merely distracting.
2002-07-07 05:13:56 +00:00
Tim Peters 943382c8e5 Removed WITH_CYCLE_GC #ifdef-ery. Holes:
+ I'm not sure what to do about configure.in.  Left it alone.

+ Ditto pyexpat.c.  Fred or Martin will know what to do.
2002-07-07 03:59:34 +00:00
Michael W. Hudson 8b7f131f8b gc_list_move defined but not used. 2002-07-04 17:11:36 +00:00
Tim Peters aab713bdf7 visit_decref(): Added another assert. 2002-07-02 22:15:28 +00:00
Tim Peters 6fc13d9595 Finished transitioning to using gc_refs to track gc objects' states.
This was mostly a matter of adding comments and light code rearrangement.
Upon untracking, gc_next is still set to NULL.  It's a cheap way to
provoke memory faults if calling code is insane.  It's also used in some
way by the trashcan mechanism.
2002-07-02 18:12:35 +00:00