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