* 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.
This is a verifier for the binary code used by the _sre module (this
is often called bytecode, though to distinguish it from Python bytecode
I put it in quotes).
I wrote this for Google App Engine, and am making the patch available as
open source under the Apache 2 license. Below are the copyright
statement and license, for completeness.
# Copyright 2008 Google Inc.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
It's not necessary to include these copyrights and bytecode in the
source file. Google has signed a contributor's agreement with the PSF
already.
This patch publishes the work done until now
for Python 3.0 compatibility. Still a lot
to be done.
When possible, we use 3.0 features in Python 2.6,
easing development and testing, and exposing internal
changes to a wider audience, for better test coverage.
Some mode details:
http://www.jcea.es/programacion/pybsddb.htm#bsddb3-4.7.2
was not always being done properly in some python types and extension
modules. PyMem_MALLOC, PyMem_REALLOC, PyMem_NEW and PyMem_RESIZE have
all been updated to perform better checks and places in the code that
would previously leak memory on the error path when such an allocation
failed have been fixed.
process rather than both parent and child.
Does anyone actually use fork1()? It appears to be a Solaris thing
but if Python is built with pthreads on Solaris, fork1() and fork()
should be the same.
When a thread touches such an object for the first time, a new thread-local __dict__ is created,
and the __init__ method is run.
But a thread switch can occur here; if the other thread touches the same object, it installs another
__dict__; when the first thread resumes, it updates the dictionary of the second...
This is the deep cause of the failures in test_multiprocessing involving "managers" objects.
Also a 2.5 backport candidate.
behaviours. I left the original test commented out (note
that that test came from #2702, which seems to have a
problem in FreeBSD and Windows, but not in Linux).
I included a new test, to watch over the now-broken
behaviour, I took it from #3179.
Some functions in the msvcrt module are skipped,
and socket.ioctl is enabled only when using a more recent Platform SDK.
(and yes, there are still companies that use a 10-years old compiler)
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.
occurances of PyBytes_ in the code to their original PyString_ names. The
bytesobject.c file will be renamed back to stringobject.c in a future checkin.
ctypes maintains thread-local storage that has space for two error
numbers: private copies of the system 'errno' value and, on Windows,
the system error code accessed by the GetLastError() and
SetLastError() api functions.
Foreign functions created with CDLL(..., use_errno=True), when called,
swap the system 'errno' value with the private copy just before the
actual function call, and swapped again immediately afterwards. The
'use_errno' parameter defaults to False, in this case 'ctypes_errno'
is not touched.
On Windows, foreign functions created with CDLL(...,
use_last_error=True) or WinDLL(..., use_last_error=True) swap the
system LastError value with the ctypes private copy.
The values are also swapped immeditately before and after ctypes
callback functions are called, if the callbacks are constructed using
the new optional use_errno parameter set to True: CFUNCTYPE(...,
use_errno=TRUE) or WINFUNCTYPE(..., use_errno=True).
New ctypes functions are provided to access the ctypes private copies
from Python:
- ctypes.set_errno(value) and ctypes.set_last_error(value) store
'value' in the private copy and returns the previous value.
- ctypes.get_errno() and ctypes.get_last_error() returns the current
ctypes private copies value.
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.
convention that allows safe access to errno)
This code does not yet work on OS X (__thread storage specifier not
available), so i needs a configure check plus a more portable
solution.
errno (and LastError, on Windows).
ctypes maintains a module-global, but thread-local, variable that
contains an error number; called 'ctypes_errno' for this discussion.
This variable is a private copy of the systems 'errno' value; the copy
is swapped with the 'errno' variable on several occasions.
Foreign functions created with CDLL(..., use_errno=True), when called,
swap the values just before the actual function call, and swapped
again immediately afterwards. The 'use_errno' parameter defaults to
False, in this case 'ctypes_errno' is not touched.
The values are also swapped immeditately before and after ctypes
callback functions are called, if the callbacks are constructed using
the new optional use_errno parameter set to True: CFUNCTYPE(..., use_errno=TRUE)
or WINFUNCTYPE(..., use_errno=True).
Two new ctypes functions are provided to access the 'ctypes_errno'
value from Python:
- ctypes.set_errno(value) sets ctypes_errno to 'value', the previous
ctypes_errno value is returned.
- ctypes.get_errno() returns the current ctypes_errno value.
---
On Windows, the same scheme is implemented for the error value which
is managed by the GetLastError() and SetLastError() windows api calls.
The ctypes functions are 'ctypes.set_last_error(value)' and
'ctypes.get_last_error()', the CDLL and WinDLL optional parameter is
named 'use_last_error', defaults to False.
---
On Windows, TlsSetValue and TlsGetValue calls are used to provide
thread local storage for the variables; ctypes compiled with __GNUC__
uses __thread variables.
* Expand comments.
* Swap variable names in the sum_exact code so that x and y
are consistently chosen as the larger and smaller magnitude
values respectively.
Renamed copy_reg to copyreg in the standard library, to avoid
spurious warnings and ease later merging to py3k branch. Public
documentation remains intact.
characters. This avoids the common case of something like 'NUMBER(10)' not
being parsed as 'NUMBER', like expected. Also corrected the docs about
converter names being case-sensitive. They aren't any longer.