I've used valgrind on my local box. I tried to find the error we're
looking for using valgrind. I was kind of hoping that valgrind was able
to find the error on x86. I've used valgrind in the past to find errors
that were expressed on one platform (were valgrind did not run), but did
not cause crashes on the 'valgrind-platform'. Valgrind was still able to
find the errors.
Alas, not this time..
I've been looking for a replacement for our md5 functions. We could of
course use OpenSSL's md5 (or even better, SHA1) functions. But this
would mean that we have a dependency on OpenSSL. It does give us the
opportunity to throw away some code (we could get rid of the md5.c and
md5.h files) that is not understood by most people (including me).
I remember something about the GPL not being compatible with OpenSSL's
license. Does anybody know if this also applies to linking?
Ilja
Paul F. De La Cruz wrote:
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?
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
