Re: PostgreSQL crashes with SIGSEGV

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: PostgreSQL crashes with SIGSEGV
Date: 2017-12-08 09:19:44
Message-ID: 1512724784.9720.39.camel@oopsware.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message mbochenk 2017-12-08 10:41:20 BUG #14954: fresh install of postgresql-server 9.6.6-3PGDG.rhel6 fails on initdb
Previous Message Bernd Helmle 2017-12-08 09:13:00 Re: PostgreSQL crashes with SIGSEGV

Browse pgsql-hackers by date

  From Date Subject
Next Message Tels 2017-12-08 09:24:45 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Michael Paquier 2017-12-08 09:13:02 Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.