python3.11/python3-disable-pymalloc-on-valgrind.patch
2012-02-01 19:19:07 +04:00

122 lines
3.9 KiB
Diff

diff -p -up Python-3.1.2/configure.in.valgrind~ Python-3.1.2/configure.in
--- Python-3.1.2/configure.in.valgrind~ 2010-05-27 23:59:21.955477329 +0200
+++ Python-3.1.2/configure.in 2010-05-27 23:59:47.150476510 +0200
@@ -2478,6 +2478,19 @@ then
fi
AC_MSG_RESULT($with_pymalloc)
+# Check for Valgrind support
+AC_MSG_CHECKING([for --with-valgrind])
+AC_ARG_WITH([valgrind],
+ AC_HELP_STRING([--with-valgrind], [Enable Valgrind support]),,
+ with_valgrind=no)
+AC_MSG_RESULT([$with_valgrind])
+if test "$with_valgrind" != no; then
+ AC_CHECK_HEADER([valgrind/valgrind.h],
+ [AC_DEFINE([WITH_VALGRIND], 1, [Define if you want pymalloc to be disabled when running under valgrind])],
+ [AC_MSG_ERROR([Valgrind support requested but headers not available])]
+ )
+fi
+
# Check for --with-wctype-functions
AC_MSG_CHECKING(for --with-wctype-functions)
AC_ARG_WITH(wctype-functions,
diff -p -up Python-3.1.2/Misc/NEWS.valgrind~ Python-3.1.2/Misc/NEWS
--- Python-3.1.2/Misc/NEWS.valgrind~ 2010-05-27 23:59:20.795726096 +0200
+++ Python-3.1.2/Misc/NEWS 2010-05-27 23:59:47.154486551 +0200
@@ -119,6 +119,11 @@ Core and Builtins
- Issue #6750: A text file opened with io.open() could duplicate its output
when writing from multiple threads at the same time.
+- Issue #2422: When compiled with the ``--with-valgrind`` option, the
+ pymalloc allocator will be automatically disabled when running under
+ Valgrind. This gives improved memory leak detection when running
+ under Valgrind, while taking advantage of pymalloc at other times.
+
Library
-------
diff -p -up Python-3.1.2/Objects/obmalloc.c.valgrind~ Python-3.1.2/Objects/obmalloc.c
--- Python-3.1.2/Objects/obmalloc.c.valgrind~ 2010-05-27 23:59:21.931726329 +0200
+++ Python-3.1.2/Objects/obmalloc.c 2010-05-27 23:59:47.152476257 +0200
@@ -2,6 +2,21 @@
#ifdef WITH_PYMALLOC
+#ifdef WITH_VALGRIND
+#include <valgrind/valgrind.h>
+
+/* If we're using GCC, use __builtin_expect() to reduce overhead of
+ the valgrind checks */
+#if defined(__GNUC__) && (__GNUC__ > 2) && defined(__OPTIMIZE__)
+# define UNLIKELY(value) __builtin_expect((value), 0)
+#else
+# define UNLIKELY(value) (value)
+#endif
+
+/* -1 indicates that we haven't checked that we're running on valgrind yet. */
+static int running_on_valgrind = -1;
+#endif
+
/* An object allocator for Python.
Here is an introduction to the layers of the Python memory architecture,
@@ -728,6 +743,13 @@ PyObject_Malloc(size_t nbytes)
poolp next;
uint size;
+#ifdef WITH_VALGRIND
+ if (UNLIKELY(running_on_valgrind == -1))
+ running_on_valgrind = RUNNING_ON_VALGRIND;
+ if (UNLIKELY(running_on_valgrind))
+ goto redirect;
+#endif
+
/*
* Limit ourselves to PY_SSIZE_T_MAX bytes to prevent security holes.
* Most python internals blindly use a signed Py_ssize_t to track
@@ -927,6 +949,11 @@ PyObject_Free(void *p)
if (p == NULL) /* free(NULL) has no effect */
return;
+#ifdef WITH_VALGRIND
+ if (UNLIKELY(running_on_valgrind > 0))
+ goto redirect;
+#endif
+
pool = POOL_ADDR(p);
if (Py_ADDRESS_IN_RANGE(p, pool)) {
/* We allocated this address. */
@@ -1121,6 +1148,9 @@ PyObject_Free(void *p)
return;
}
+#ifdef WITH_VALGRIND
+redirect:
+#endif
/* We didn't allocate this address. */
free(p);
}
@@ -1150,6 +1180,12 @@ PyObject_Realloc(void *p, size_t nbytes)
if (nbytes > PY_SSIZE_T_MAX)
return NULL;
+#ifdef WITH_VALGRIND
+ /* Treat running_on_valgrind == -1 the same as 0 */
+ if (UNLIKELY(running_on_valgrind > 0))
+ goto redirect;
+#endif
+
pool = POOL_ADDR(p);
if (Py_ADDRESS_IN_RANGE(p, pool)) {
/* We're in charge of this block */
@@ -1177,6 +1213,9 @@ PyObject_Realloc(void *p, size_t nbytes)
}
return bp;
}
+#ifdef WITH_VALGRIND
+ redirect:
+#endif
/* We're not managing this block. If nbytes <=
* SMALL_REQUEST_THRESHOLD, it's tempting to try to take over this
* block. However, if we do, we need to copy the valid data from