On 2016-04-10 22:03:53 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > On 2016-04-10 17:55:25 -0400, Tom Lane wrote:
> >> Hmm.  It's true that I don't have the python debuginfo RPM installed.
> >> But this is a live bug, so I suspect you were too generous about
> >> those suppressions.
> 
> > Could be - I just used the ones (after adapting for 32 vs. 64 bit
> > issues) provided by upstream.
> 
> I still see the same failure after installing python-debuginfo:
> 
> ==00:00:00:55.235 18250== Invalid read of size 1
> ==00:00:00:55.235 18250==    at 0x4A07F92: strlen (mc_replace_strmem.c:403)
> ==00:00:00:55.235 18250==    by 0x826860: MemoryContextStrdup (mcxt.c:1158)
> ==00:00:00:55.235 18250==    by 0x800441: set_errdata_field (elog.c:1230)
> ==00:00:00:55.235 18250==    by 0x803EE8: err_generic_string (elog.c:1210)
> ==00:00:00:55.235 18250==    by 0xDFEF2DD: PLy_elog (plpy_elog.c:117)
> ==00:00:00:55.235 18250==    by 0xDFF018D: PLy_procedure_call 
> (plpy_exec.c:1084)
> ==00:00:00:55.235 18250==    by 0xDFF14C6: PLy_exec_function (plpy_exec.c:105)
> ==00:00:00:55.235 18250==    by 0xDFF2103: plpython_inline_handler 
> (plpy_main.c:345)
> ==00:00:00:55.235 18250==    by 0x809737: OidFunctionCall1Coll (fmgr.c:1596)
> ==00:00:00:55.235 18250==    by 0x70E97F: standard_ProcessUtility 
> (utility.c:515)
> ==00:00:00:55.235 18250==    by 0x70A856: PortalRunUtility (pquery.c:1175)
> ==00:00:00:55.235 18250==    by 0x70B8FF: PortalRunMulti (pquery.c:1306)
> ==00:00:00:55.235 18250==  Address 0xefe1954 is 36 bytes inside a block of 
> size 49 free'd
> ==00:00:00:55.235 18250==    at 0x4A06430: free (vg_replace_malloc.c:446)
> ==00:00:00:55.235 18250==    by 0x398AE90D5C: tupledealloc (tupleobject.c:170)
> ==00:00:00:55.235 18250==    by 0x398AE79E3A: dict_dealloc (dictobject.c:911)
> ==00:00:00:55.235 18250==    by 0x398AE5C586: BaseException_clear 
> (exceptions.c:77)
> ==00:00:00:55.235 18250==    by 0x398AE5C5BF: BaseException_dealloc 
> (exceptions.c:87)
> ==00:00:00:55.235 18250==    by 0x398AE9A704: subtype_dealloc 
> (typeobject.c:1019)
> ==00:00:00:55.236 18250==    by 0xDFEEDBC: PLy_traceback (plpy_elog.c:358)
> ==00:00:00:55.236 18250==    by 0xDFEF154: PLy_elog (plpy_elog.c:83)
> ==00:00:00:55.236 18250==    by 0xDFF018D: PLy_procedure_call 
> (plpy_exec.c:1084)
> ==00:00:00:55.236 18250==    by 0xDFF14C6: PLy_exec_function (plpy_exec.c:105)
> ==00:00:00:55.236 18250==    by 0xDFF2103: plpython_inline_handler 
> (plpy_main.c:345)
> ==00:00:00:55.236 18250==    by 0x809737: OidFunctionCall1Coll (fmgr.c:1596)
> 
> 
> With the patch I'm working on, no error, not even with the python-specific
> suppressions all removed from valgrind.supp.  Not sure what to make of
> that.  RHEL6's version of python is 2.6.6, which is not real new, but
> the documentation that comes with it indicates that the false-valgrind-
> warnings problem exists.

I downloaded the RHEL6 srpm, and it appears to be patched to
automatically disable pymalloc when running under valgrind (via
disable-pymalloc-on-valgrind-py26.patch).  That explains why you're
seing the problem, but skink isn't (it's running debian).

Greetings,

Andres Freund
diff -up Python-2.6.6/configure.in.disable-pymalloc-on-valgrind Python-2.6.6/configure.in
--- Python-2.6.6/configure.in.disable-pymalloc-on-valgrind	2010-11-29 15:45:07.199350502 -0500
+++ Python-2.6.6/configure.in	2010-11-29 15:45:07.208351260 -0500
@@ -2538,6 +2538,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 -up Python-2.6.6/Misc/NEWS.disable-pymalloc-on-valgrind Python-2.6.6/Misc/NEWS
--- Python-2.6.6/Misc/NEWS.disable-pymalloc-on-valgrind	2010-08-23 19:37:56.000000000 -0400
+++ Python-2.6.6/Misc/NEWS	2010-11-29 15:45:07.209350567 -0500
@@ -21,6 +21,11 @@ What's New in Python 2.6.6 rc 2?
 
 *Release date: 2010-08-16*
 
+- 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 -up Python-2.6.6/Objects/obmalloc.c.disable-pymalloc-on-valgrind Python-2.6.6/Objects/obmalloc.c
--- Python-2.6.6/Objects/obmalloc.c.disable-pymalloc-on-valgrind	2010-05-09 11:15:40.000000000 -0400
+++ Python-2.6.6/Objects/obmalloc.c	2010-11-29 15:45:07.209350567 -0500
@@ -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,
@@ -737,6 +752,13 @@ PyObject_Malloc(size_t nbytes)
     if (nbytes > PY_SSIZE_T_MAX)
         return NULL;
 
+#ifdef WITH_VALGRIND
+    if (UNLIKELY(running_on_valgrind == -1))
+        running_on_valgrind = RUNNING_ON_VALGRIND;
+    if (UNLIKELY(running_on_valgrind))
+        goto redirect;
+#endif
+
     /*
      * This implicitly redirects malloc(0).
      */
@@ -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,7 @@ PyObject_Free(void *p)
         return;
     }
 
+redirect:
     /* We didn't allocate this address. */
     free(p);
 }
@@ -1150,6 +1178,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 +1211,7 @@ PyObject_Realloc(void *p, size_t nbytes)
         }
         return bp;
     }
+redirect:
     /* 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
diff -up Python-2.6.6/pyconfig.h.in.disable-pymalloc-on-valgrind Python-2.6.6/pyconfig.h.in
--- Python-2.6.6/pyconfig.h.in.disable-pymalloc-on-valgrind	2009-10-27 08:30:12.000000000 -0400
+++ Python-2.6.6/pyconfig.h.in	2010-11-29 15:45:07.209350567 -0500
@@ -1085,6 +1085,9 @@
 /* Define to empty if the keyword does not work. */
 #undef volatile
 
+/* Define if you want pymalloc to be disabled when running under valgrind */
+#undef WITH_VALGRIND
+
 
 /* Define the macros needed if on a UnixWare 7.x system. */
 #if defined(__USLC__) && defined(__SCO_VERSION__)
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to