| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewer: Georg Brandl, Benjamin Peterson
|
| |
|
|
|
|
|
| |
exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.
Reviewed by Amaury Forgeot d'Arc.
|
| |
|
|
|
|
|
|
|
|
| |
match Python 2.5 speed despite the __instancecheck__ / __subclasscheck__
mechanism. In the process, fix a bug where isinstance() and issubclass(),
when given a tuple of classes as second argument, were looking up
__instancecheck__ / __subclasscheck__ on the tuple rather than on each
type object.
Reviewed by Benjamin Peterson and Raymond Hettinger.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* crashes on memory allocation failure found with failmalloc
* memory leaks found with valgrind
* compiler warnings in opt mode which would lead to invalid memory reads
* problem using wrong name in decimal module reported by pychecker
Update the valgrind suppressions file with new leaks that are small/one-time
leaks we don't care about (ie, they are too hard to fix).
TBR=barry
TESTED=./python -E -tt ./Lib/test/regrtest.py -uall (both debug and opt modes)
in opt mode:
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py -uall,-bsddb,-compiler \
-x test_logging test_ssl test_multiprocessing
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py test_multiprocessing
for i in `seq 1 4000` ; do
LD_PRELOAD=~/local/lib/libfailmalloc.so FAILMALLOC_INTERVAL=$i \
./python -c pass
done
At least some of these fixes should probably be backported to 2.5.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
by denying s# to parse objects that have a releasebuffer procedure,
and introducing s*.
More module might need to get converted to use s*.
|
| |
|
|
| |
has been removed there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
key list data structure in the thread startup path.
This change is a companion to r60148 which already successfully dealt with a
similar issue on thread shutdown.
In particular this loop has been observed happening from this call path:
#0 in find_key ()
#1 in PyThread_set_key_value ()
#2 in _PyGILState_NoteThreadState ()
#3 in PyThreadState_New ()
#4 in t_bootstrap ()
#5 in pthread_start_thread ()
I don't know how this happens but it does, *very* rarely. On more than
one hardware platform. I have not been able to reproduce it manually.
(A flaky mutex implementation on the system in question is one hypothesis).
As with r60148, the spinning we managed to observe in the wild was due to a
single list element pointing back upon itself.
|
| |
|
|
|
|
| |
The argument was fetched in a long, but PyUnicode_FromOrdinal takes an int.
(why doesn't gcc issue a truncation warning in this case?)
|
| |
|
|
| |
make sure that PyErr_ExceptionMatches returns 0 when an exception occurs there.
|
| |
|
|
| |
(35% faster according to pybench)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
when the parent module can't be found during an absolute import (likely due to non-PEP 361 aware code which sets a module level __package__ attribute)
|
| |
|
|
| |
#3343: Py_DisplaySourceLine should be a private function. Rename it to _Py_DisplaySourceLine.
|
| |
|
|
| |
sys.getsizeof.
|
| | |
|
| |
|
|
|
| |
freelists. Changes their CompactFreeList apis into ClearFreeList apis and
calls them via gc.collect().
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
whose write() method installs another sys.stdout.
Will backport.
|
| | |
|
| |
|
|
|
|
|
|
| |
bus errors or SystemError being raised. As a side effect of fixing this, a bad
DECREF that could be triggered when 'message' and 'category' were both None was
fixed.
Closes issue 3211. Thanks JP Calderone for the bug report.
|
| | |
|
| |
|
|
| |
anticipation of fixing issue 3140.
|
| |
|
|
| |
subclasses can override or so that other classes can support.
|
| | |
|
| |
|
|
| |
This should prevent some test_multiprocessing failures
|
| |
|
|
|
|
| |
Added checks for integer overflows, contributed by Google. Some are
only available if asserts are left in the code, in cases where they
can't be triggered from Python code.
|
| |
|
|
|
|
|
| |
http://mail.python.org/pipermail/python-dev/2008-June/079988.html
Python 2.6 should stick with PyString_* in its codebase. The PyBytes_* names
in the spirit of 3.0 are available via a #define only. See the email thread.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
optimizations.
|
| | |
|
