Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Leif Jackson
Aaron, I would try valgrind, they should have it installed. It does well on all kinds of bounds checking, as well as memory and cache checks. -Leif Hey, So I whipped up a little wrapper program around read_header() and makemd5() that crashes on the Opteron server at SourceForge, but

Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Aaron Stone
Valgrind emulates a Pentium instruction set, so it's not useful on an x86-64 processor. They have gdb 5.3 installed, and I just compiled gdb 6.0 for myself, both of which give me this when I try to read the backtrace: [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software

Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Leif Jackson
Aaron, no problems being 64bit clean on sun solaris9: bash-2.05$ gcc -DHAVE_CONFIG_H -I. -I. -I.-fomit-frame-pointer -g -m64 -O2 -W -Wall -Wpointer-arith -Wstrict-prototypes -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o testmd5.c: In function `main': testmd5.c:58: warning: unused

Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Aaron Stone
Looks like 64 bit by default on the Opteron... [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped debug.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped header.o: ELF 64-bit LSB relocatable,

Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Leif Jackson
Humm well it isn't our code that's not 64bit clean, as I emailed in the previous message, try compiling just thouse objects with -m32 or the equiv if you can and see what happens. -leif Looks like 64 bit by default on the Opteron... [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o:

Re: [Dbmail-dev] MD5 bug reproduced on Opteron

2004-03-06 Thread Aaron Stone
Fixed. Turned out to be quite simple: In md5.h, find the #ifdef __alpha and change it to this: #if (defined(__alpha) || defined(__x86_64__)) typedef unsigned int uint32; #else typedef unsigned long uint32; #endif For whatever reason, the Sparc is still using a 32-bit int? Or perhaps it is not