Actually valgrind refuses to compile on x86_64. I tried to get it installed on the opteron server last night and it just dies on ./configure stating the cpu isn't supported. Really burst my bubble as I got settled in to try debugging dbmail-smtp yesterday. :(
---------- Original Message ------------- Subject: Re: [Dbmail-dev] md5 algorithm Date: Thu, 12 Feb 2004 17:24:47 -0000 From: "Aaron Stone" <[EMAIL PROTECTED]> Ilja Booij <[EMAIL PROTECTED]> said: > > Ok, try this: in makemd5(), change result[16] to be twice as large. Don't > > change the size of the malloc(33), since we can use valgrind to try to > > catch the memory error to confirm my theory. What I'm thinking is that > > perhaps the gdm_md5_final() function is producing a larger result due to > > being 64 bit, and smashing the stack by running off the end of result[16]. > Doesn't help I'm afraid. > > Strange thing though. Without -O2, the error seems to be in md5 > functions(), but with -O2, it's in a PQEscapeString (on PostgreSQL of > course) In my experience, when a problem moves around due to optimization, it's either because you're triggering a different segfault somewhere else first, and your original bug and a new bug have been uncovered... or because there's an overflow somewhere way out in left field that's randomly screwing things up just depending upon the layout of the functions in memory :-\ It occurs to me that valgrind actually emulates a Pentium instruction set. I might be on a wild goose chase with the 64-bit thing, but valgrind should either be unable to monitor such a program or just freak out about the 64-bits and the additional x86-64 instructions that it doesn't know about... or perhaps it just glosses over them like it does with SSE, etc?
