revision 1.73 of marshal.c
Fix SF 588452: debug build crashes on marshal.dumps([128] * 1000).
See there for a description.
Added test case.
Bugfix candidate for 2.2.x, not sure about previous versions:
probably low priority, because virtually no one runs debug builds.
1.39:
Fix SF bug 610610 (reported by Martijn Pieters, diagnosed by Neal Norwitz).
The switch in Exception__str__ didn't clear the error if
PySequence_Size() raised an exception. Added a case -1 which clears
the error and falls through to the default case.
1.40:
Two more cases of switch(PySequence_Size()) without checking for case -1.
(Same problem as last checkin for SF bug 610610)
Need to clear the error and proceed.
SF bug 567538: Generator can crash the interpreter (Finn Bock).
This was a simple typo. Strange that the compiler didn't catch it!
Instead of WHY_CONTINUE, two tests used CONTINUE_LOOP, which isn't a
why_code at all, but an opcode; but even though 'why' is declared as
an enum, comparing it to an int is apparently not even worth a
warning -- not in gcc, and not in VC++. :-(
if co_stacksize was > 32767 (the maximum value
which can be stored in 16 bits (signed)),
the PyCodeObject would be written wrong.
So on the second import (reading the .pyc)
would cause a crash.
Since we can't change the PYC magic, we
go on (silently), but don't write the file.
This means everything will work, but
a .pyc will not be written and the file will need
to be parsed on each import.
I will backport.
Repair widespread misuse of _PyString_Resize. Since it's clear people
don't understand how this function works, also beefed up the docs. The
most common usage error is of this form (often spread out across gotos):
if (_PyString_Resize(&s, n) < 0) {
Py_DECREF(s);
s = NULL;
goto outtahere;
}
The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL. So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s): s is already
NULL! A correct way to write the above is the simpler (and intended)
if (_PyString_Resize(&s, n) < 0)
goto outtahere;
Bugfix candidate.
Original patch(es):
python/dist/src/Python/bltinmodule.c:2.253
If you think I've forgotten something, now is a good
time to howl (although I won't read the howl for a good
few hours 'cause I'm going home).
backport lemburg's checkin of
revision 2.158 of pythonrun.c
Move Unicode finalization further down in the chain.
Fixes bug #525620.
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 an issue that was reported in but unrelated to the main problem of
SF bug 535905 (Evil Trashcan and GC interaction).
The SETLOCAL() macro should not DECREF the local variable in-place and
then store the new value; it should copy the old value to a temporary
value, then store the new value, and then DECREF the temporary value.
This is because it is possible that during the DECREF the frame is
accessed by other code (e.g. a __del__ method or gc.collect()) and the
variable would be pointing to already-freed memory.
BUGFIX CANDIDATE!
revision 2.248 of bltinmodule.c
Docstring for filter(): Someone on the Tutor list reasonably complained
that it didn't tell enough of the truth.
Bugfix candidate (I guess -- it helps and it's harmless).
revision 2.22 of thread_nt.h
SF patch 522961: Leak in Python/thread_nt.h, from Gerald S. Williams.
A file-static "threads" dict mapped thread IDs to Windows handles, but
was never referenced, and entries never got removed. This gets rid of
the YAGNI-dict entirely.
Bugfix candidate.
Workaround for what is probably a problem in Apple's gcc: <pthread.h> fails
on a function pointer formal argument called "destructor", which is typedeffed
as a different function pointer type in object.h.
Backport gvanrossum's checkin of revision 2.236:
A tentative fix for SF bug #503837 (Roeland Rengelink):
type.__module__ problems (again?)
This simply initializes the __module__ local in a class statement from
the __name__ global. I'm not 100% sure that this is the correct fix,
although it usually does the right thing. The problem is that if the
class statement executes in a custom namespace, the __name__ global
may be taken from __builtins__, in which case it would have the value
__builtin__, or it may not exist at all (if the custom namespace also
has a custom __builtins__), in which case the class statement will
fail.
Nevertheless, unless someone finds a better solution, this is a 2.2.1
bugfix too.
(apparently noone has :()
