Re: overlapping strncpy/memcpy errors via valgrind

On 2013-02-17 19:52:16 +0000, Peter Geoghegan wrote:
> On 17 February 2013 19:39, anarazel(at)anarazel(dot)de <andres(at)anarazel(dot)de> wrote:
> > What patch are you talking about? I have no knowledge about any pending valgrind patches except one I made upstream apply to make pg inside valgrind work on amd64.
>
> Noah wrote a small patch, which he shared with me privately, which
> added Valgrind hook macros to aset.c and mcxt.c. The resulting
> Valgrind run threw up some things that were reported publicly [1]. I
> documented much of his work on the wiki. I was under the impression
> that this was the best way to get Valgrind to work with Postgres
> (apparently there were problems with many false positives otherwise).
>
> [1] http://www.postgresql.org/message-id/20110312133224.GA7833@tornado.gateway.2wire.net

Nice, I wasn't aware of that work. I always wanted to add that
instrumentation but never got arround to it.
PG runs without problems for me with the exception of some warnings that
I suppress.
Would be nice to get that upstream...

> For reasons that have yet to be ascertained, it is necessary to run the
> regression tests with autovacuum = 'off'. Otherwise, Postgres will segfault
> within an autovacuum worker's elog() call.

That's the bug I was referring to, its fixed at least in svn. It failed
in far more places than that, basically everywhere an instruction that
required the stack to be properly aligned was executed.
The problem was that valgrind didn't align the new stack properly after
a fork if the fork was executed inside a signal handler. Which pg
happens to do...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services