Postgres Pro
Downloads
Home   >   mailing lists

Thread: pltcl valgrind output

pltcl valgrind output

From
Andrew Dunstan
Date:
I've been adding support for valgrind to the buildfarm client (code will
hit the git repo shortly). Mostly the results have been pretty clean,
but the pltcl tests generated the attached output. Perhaps someone with
more valgrind-fu than I have so far would like to use the information to
extend our supp file appropriately (or fix what it's complaining about).


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment

Re: pltcl valgrind output

From
Andrew Dunstan
Date:

On 12/18/2017 10:12 AM, Andrew Dunstan wrote:
> I've been adding support for valgrind to the buildfarm client (code will
> hit the git repo shortly). Mostly the results have been pretty clean,
> but the pltcl tests generated the attached output. Perhaps someone with
> more valgrind-fu than I have so far would like to use the information to
> extend our supp file appropriately (or fix what it's complaining about).


The following appears to keep valgrind quiet. AFAICT the problem isn't
in our code.

    diff --git a/src/tools/valgrind.supp b/src/tools/valgrind.supp
    index af03051..24c6f5b 100644
    --- a/src/tools/valgrind.supp
    +++ b/src/tools/valgrind.supp
    @@ -212,3 +212,11 @@
        Memcheck:Cond
        fun:PyObject_Realloc
     }
    +
    +#### issue with TclNRRunCallbacks
    +{
    +   tcl_callback
    +   Memcheck:Cond
    +   ...
    +   fun:TclNRRunCallbacks
    +}


cheers

andrew


-- 

Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: pltcl valgrind output

From
Tom Lane
Date:
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> The following appears to keep valgrind quiet. AFAICT the problem isn't
> in our code.

I'm a little worried about whether this could suppress reports that
we do need to hear about.  I don't know what TclNRRunCallbacks is
or does exactly, but just going by the name, it seems like it could
invoke non-Tcl code (ie, callbacks supplied by us).  It'd be better
to constrain the call stack more tightly, particularly what the top
function is.

I agree that the traces you showed before don't look like our fault.

            regards, tom lane