Horton

Re: PostgreSQL crashes with SIGSEGV

Bernd Helmle <mailings@oopsware.de>

View thread View on postgr.es
From: Bernd Helmle <mailings@oopsware.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: pgsql-bugs@postgresql.org
Date: 2017-12-08T09:19:44Z
Lists: pgsql-bugs, pgsql-hackers 
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

Commits

  1. Fix actual and potential double-frees around tuplesort usage.

  2. Allow the built-in ordered-set aggregates to share transition state.

  3. Avoid integer overflow while sifting-up a heap in tuplesort.c.

  4. Allow avoiding tuple copy within tuplesort_gettupleslot().

  5. Remove should_free arguments to tuplesort routines.

  6. Fix use-after-free around DISTINCT transition function calls.

  7. Reuse abbreviated keys in ordered [set] aggregates.