On Sun, Sep 12, 2010 at 7:54 AM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> 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.
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.
