Re: Weird irreproducible behaviors in plpython tests

On 2016-04-10 22:03:53 -0400, Tom Lane wrote:
> Andres Freund <andres@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