Re: Huge amount of memory errors with libpq

On 09/12/2010 02:53 PM, Casey Jones wrote:

> My development server was initially running 8.4.4 on Gentoo.  I downgraded to
> 8.1.21 (still on Gentoo) to match my CentOS production server to see if the
> problems would go away, but they didn't.

Thanks for the test case. It's rare - and delightful - to see a neat,
minimal test case for any kind of question or issue report posted here.

The test case helps eliminate any outside code as a problem. In this
case, though, it's almost certainly that valgrind doesn't know about
glibc's sse3 code, for which it needs additional suppressions to handle
apparent memory errors that are in fact OK.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583856

Anyway, since you've provided a test program, I can at least run it here
on a modern PostgreSQL and see what results I get to provide some more
info. In this case, it runs fine and no issues are detected. I'm on a
64-bit Fedora 13 install with glibc 2.12.3 and postgresql 9.0rc1 , so
it's not exactly a close match for your system. It is a Core 2 Duo, so
it's SSE3 capable hardware as confirmed by /proc/cpuinfo. I'm using
valgrind 3.5.0 .

$ valgrind --tool=memcheck --leak-check=full ./a.out
==26001== Memcheck, a memory error detector
==26001== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==26001== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==26001== Command: ./a.out
==26001==
==26001==
==26001== HEAP SUMMARY:
==26001==     in use at exit: 0 bytes in 0 blocks
==26001==   total heap usage: 102 allocs, 102 frees, 47,606 bytes allocated
==26001==
==26001== All heap blocks were freed -- no leaks are possible
==26001==
==26001== For counts of detected and suppressed errors, rerun with: -v
==26001== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)


Looking at the trace from yours, it appears to me that it's trying to
use an operation with an 8 byte input on the last four bytes of a
12-byte string. That string is certainly going to be "dbname=mydb\0", as
"dbname=mydb" is 11 bytes long and is the conninfo string being supplied
to libpq.

It's hard to see how strcmp could perform an incorrect read on that due
to bad input from libpq, so long as the null-terminator is present on at
least the shorter of the inputs if not both. In this case it's present
on the string the error report complains about, excluding a missing
terminator as a problem cause. There's no length argument to be wrong,
nothing much else at all to be wrong in what libpq supplies to libc.

I strongly suspect that glibc is doing funky magic with sse3 string
operations that cause apparently invalid reads that are actually safe,
*or* there's an issue with valgrind its self.

It'd be interesting to test the following program:


#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
     int cmpresult = strcmp("user", strdup("dbname=classads"));
     printf("Comparison: %i\n", cmpresult);
}



... to see if it, too, reports errors from valgrind. It doesn't here, of
course (though interestingly strcmp returns 1 under valgrind and 17
outside it); I'd like to see what your results are.

--
Craig Ringer