Message-ID: <1512724784.9720.39.camel@oopsware.de>
Subject: Re: PostgreSQL crashes with SIGSEGV
From: Bernd Helmle <mailings@oopsware.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: pgsql-bugs@postgresql.org
Date: Fri, 08 Dec 2017 10:19:44 +0100
In-Reply-To: 
 <CAH2-WznDBGQXBE=n3vXWLDomjAbJQz15xK3+hxh-Y92F0eTaBg@mail.gmail.com>
References: <1512661638.9720.34.camel@oopsware.de>
	 <CAH2-WznDBGQXBE=n3vXWLDomjAbJQz15xK3+hxh-Y92F0eTaBg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

Am Donnerstag, den 07.12.2017, 18:54 -0800 schrieb Peter Geoghegan:
> So, as you said, the question that we probably need to answer is:
> just
> how did grouping sets/nodeAgg.c code end up getting tuple memory
> lifetime wrong. One good way to get more information is to rerun
> Valgrind, but this time with track origins enabled. I myself run
> Valgrind like this when I want to see the origin of memory involved
> in
> an error. I specify:
> 
> $ valgrind --leak-check=no --gen-suppressions=all --trace-
> children=yes
> --track-origins=yes --read-var-info=yes
> --
> suppressions=/home/pg/postgresql/root/source/src/tools/valgrind.supp
> -v postgres --log_line_prefix="%m %p " --log_statement=all
> --shared_buffers=64MB 2>&1 | tee postmaster.log
> 
> (Probably the only change that you'll need is to make is to run
> Valgrind with an the extra "--track-origins=yes".)
> 
> --track-origins=yes is usually something I use when I already know
> that Valgrind will complain, but want more information about the
> nature of the problem.

That's what i've already did. My usage of valgrind was this:

valgrind --leak-check=no --gen-suppressions=all \
--track-origins=yes --suppressions=src/tools/valgrind.supp \
--time-stamp=yes --trace-children=yes postgres