pltcl valgrind output

Started by Andrew Dunstanabout 8 years ago3 messages
#1Andrew Dunstan
andrew.dunstan@2ndquadrant.com
1 attachment(s)

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

Attachments:

valgrind.logtext/x-log; name=valgrind.logDownload
#2Andrew Dunstan
andrew.dunstan@2ndquadrant.com
In reply to: Andrew Dunstan (#1)
Re: pltcl valgrind output

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

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#2)
Re: pltcl valgrind output

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