On 2016-04-10 22:03:53 -0400, Tom Lane wrote:
> Andres Freund <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
