Re: Huge amount of memory errors with libpq

On Sun, Sep 12, 2010 at 7:54 AM, Craig Ringer
<craig(at)postnewspapers(dot)com(dot)au>wrote:
>
> 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 .
>

I use a AMD Athlon II X4. It's based off the new Phenom II's, so it
certainly supports SSE3 and SSE4a as well.

> ... 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.

I get 17 as a result with or without valgrind. And I don't get any memory
errors.

==23894== Memcheck, a memory error detector
==23894== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==23894== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==23894== Command: ./a.out
==23894==
Comparison: 17
==23894==
==23894== HEAP SUMMARY:
==23894== in use at exit: 16 bytes in 1 blocks
==23894== total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==23894==
==23894== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==23894== at 0x4C260AE: malloc (vg_replace_malloc.c:195)
==23894== by 0x4EA8B41: strdup (in /lib64/libc-2.12.1.so)
==23894== by 0x40061C: main (in /home/casey/kwooty/Download/a.out)
==23894==
==23894== LEAK SUMMARY:
==23894== definitely lost: 16 bytes in 1 blocks
==23894== indirectly lost: 0 bytes in 0 blocks
==23894== possibly lost: 0 bytes in 0 blocks
==23894== still reachable: 0 bytes in 0 blocks
==23894== suppressed: 0 bytes in 0 blocks
==23894==
==23894== For counts of detected and suppressed errors, rerun with: -v
==23894== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)

This bug from Gentoo may be related, but I thought I had worked around it.
http://bugs.gentoo.org/show_bug.cgi?id=274771
It says to compile glibc with splitdebug, which I have and it got me past a
fatal error in valgrind. But it does mention sse-optimized strlen().
I just checked an older program I had written, and I'm getting tons of
errors on that too. Just a few months ago I had it down to just a couple of
errors. Now I'm seeing lots of errors ending at __strncmp_ssse3.

I don't think valgrind is the only issue here because outside valgrind my
data is getting magically overwritten. In the function causing that problem
I set all the fields I wanted to set by hand instead of using PQgetvalue().
If I leave PQexec() uncommented, my data in a totally unrelated area would
change, but when I comment it out I get the expected results. There might
be an error I'm making thats causing this, but I can't find it in valgrind
because of the huge number of errors.