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).
The tp_new implementation should initialize the errorhandler field,
otherwise this code could segfault:
from socket import socket
s = socket.__new__(socket)
s.recv(100)
(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
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!
revision 1.211 of socketmodule.c
Due to interaction between the MSL C library and the GUSI I/O library I can get reads from sockets to work consistently either for unbuffered binary files or for buffered binary files, but not for both:-(
The workaround is to force socket.makefile() to disable buffering for binary files.
Fixes bug 534625. 2.2.1 candidate.
Fix for
[ #504284 ] Last build problems on AIX
I'm ignoring the suggestion that this should be an autoconf test in the
interests of having a fix today. Feel free to quibble.
revision 2.28 of cmathmodule.c
SF bug 525705: [2.2] underflow raise OverflowException.
Another year in the quest to out-guess random C behavior.
Added macros Py_ADJUST_ERANGE1(X) and Py_ADJUST_ERANGE2(X, Y). The latter
is useful for functions with complex results. Two corrections to errno-
after-libm-call are attempted:
1. If the platform set errno to ERANGE due to underflow, clear errno.
Some unknown subset of libm versions and link options do this. It's
allowed by C89, but I never figured anyone would do it.
2. If the platform did not set errno but overflow occurred, force
errno to ERANGE. C89 required setting errno to ERANGE, but C99
doesn't. Some unknown subset of libm versions and link options do
it the C99 way now.
Bugfix candidate, but hold off until some Linux people actually try it,
with and without -lieee. I'll send a help plea to Python-Dev.
revision 2.33 of cStringIO.c
Fix SF bug #526518
The doc string for cStringIO suggested that str() of a StringIO object
was equivalent to getvalue(). This was never true, so repair the doc
string. (doctest would have helped here.)
Bug fix candidate for any past versions.
revision 2.38 of mmapmodule.c
SF bug 515943: searching for data with \0 in mmap.
mmap_find_method(): this obtained the string to find via s#, but it
ignored its length, acting as if it were \0-terminated instead.
Someone please run on Linux too (the extended test_mmap works on Windows).
Bugfix candidate.
