Re: Weird irreproducible behaviors in plpython tests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Weird irreproducible behaviors in plpython tests
Date
Msg-id 19121.1460340233@sss.pgh.pa.us
Whole thread Raw
In response to Re: Weird irreproducible behaviors in plpython tests  (Andres Freund <andres@anarazel.de>)
Responses Re: Weird irreproducible behaviors in plpython tests  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Andres Freund
Date:
Subject: Re: Weird irreproducible behaviors in plpython tests