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
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 |