Re: OSX doesn't accept identical source/target for strcpy() anymore - Mailing list pgsql-hackers

On 2013-10-28 21:14:48 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
> >> The larger problem though is what you'd do with the output.  There's
> >> enough false-positive noise from valgrind that I can't see having
> >> the buildfarm run just fail if there are any messages.  What to do
> >> instead isn't very clear.
> 
> > The false positives should be gone using the suppressions file we ship
> > these days (--suppressions=/path/to/pg/src/tools/valgrind.supp). We
> > might miss some more cases there, but it should be fairly easy to extend
> > it.
> 
> They're not all gone according to my testing; but there are far worse
> problems:

Spurious or real bugs? Inside PG or libc?



> 1. The output goes to stderr which means it's mixed in with the backend's
> normal log chatter.

That's relatively easy to fix. We could just pass --log-file
redirecting the errors somewhere special and display them there.

What I've done so far is to tell valgrind to let child processes with
errors exit with a non-zero exitcode using the --error-exitcode
parameter and specify -q to reduce the chatter upon normal process
exit. That gives at least some correlation to the errors in the failed
tests.

> 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
> I'm prepared to believe that this is some relatively old bug that Red Hat
> hasn't gotten round to including a patch for, but still it doesn't leave
> me with any warm fuzzy feeling about the practicality of routine valgrind
> testing.

Yea, I know which bug that is, I've pushed the valgrind guys into fixing
it... valgrind used to get confused about stack alignment in signal
handlers causing instructions that care about that (mostly xmm* register
using ones) to fail. elog() fails because we frequently pass many
parameters.
Since we fork processes from inside signal handlers, that situation
happens pretty often.

https://bugs.kde.org/show_bug.cgi?id=280114

3. valgrind gets floating point computations for
exp(larger_negative_double) wrong and returns the wrong error message:

regression=# SELECT exp(-808.3::float8);
ERROR:  value out of range: overflow

exp sets errno=ERANGE and returns inf. That's not supposed to happen
according to my exp(3)...

Greetings,

Andres Freund

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