Re: PostgreSQL crashes with SIGSEGV

On Thu, Dec 7, 2017 at 7:47 AM, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
> It seems the backend tries to free a minimal tuple at executor end,
> which is already gone by deleting the memory context it was allocated
> in before. ExecResetTupleTable() is looping through a list with 70
> entries, it encounters (after 6 or seven rounds) the first tuple slot
> with tts_shouldFreeMin set, all others before don't have it set:

On second thought, it seems more likely that the reason that
REL10_STABLE is unaffected is commit
3856cf9607f41245ec9462519c53f1109e781fc5. As of that commit (which
built on earlier v10 work) there is no question about memory for
tuples retrieved via tuplesort_gettupleslot() not belonging to caller
-- it must belong to caller. The old interface already resulted in
bugs in early 9.6 point releases that looked similar to this one, so I
was glad to remove it. (Note also that this picture was slightly
complicated by the performance optimization commit
fa117ee40330db401da776e7b003f047098a7d4c that followed, which made
some callers opt out of copying when that was clearly safe, but that
probably isn't important.)

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.

--
Peter Geoghegan