python3-disable-pymalloc-on-valgrind.patch

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