Re: Weird irreproducible behaviors in plpython tests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Weird irreproducible behaviors in plpython tests
Date: 2016-04-11 02:03:53
Message-ID: 19121.1460340233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-04-11 02:18:22 Re: Weird irreproducible behaviors in plpython tests
Previous Message Masahiko Sawada 2016-04-11 01:58:06 Re: Support for N synchronous standby servers - take 2