Re: [Dbmail-dev] MD5 bug reproduced on Opteron
well that makes sence. I belive solaris figures out the uint32 as it is really emulating 32bits on the 64bit kernel. I did some reading and it seems that dbmail as a whole may not benifit much from accualy being compiled 64bit, in fact it may make it slower. What is your test showing? I am glad at least we figured it out. I guess we could agree on some test data and compile it into testmd5.c instead of using stdin and then we can make sure the md5 is correct on the diff arch and 64bit vs 32bit? -leif 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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it works just find. -leif [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
Actually, I was reading some more, and it looks like the standards all mandate that int is 32 bit. The confusion is regarding long and long long where long is 32 bit on a 32 bit machine and 64 bit on a 64 bit machine and long long is 64 bit on a 32 bit machine and is usually not even defined on 64 bit machines. When I ported DBMail to Tru64 on Alpha, I had make changes to avoid long long; on Opteron, it's not an issue because of the GNU toolchain and libraries which have standardized these sorts of things. I guess same for Solaris on Sparc. I could also try it out on one of my SGI's. I think that's it for 64 bit machines, though. I have an ancient PA-RISC, but I can't imagine that it's 64 bit. Did I ever mention that I really like old UNIX workstation hardware? This MD5 code was made public domain in 1993. Perhaps at that time it was not uncommon for int to be 16 bits, however today it is extremely rare. So I just changed it to always be an unsigned int. Aaron Leif Jackson [EMAIL PROTECTED] said: well that makes sence. I belive solaris figures out the uint32 as it is really emulating 32bits on the 64bit kernel. I did some reading and it seems that dbmail as a whole may not benifit much from accualy being compiled 64bit, in fact it may make it slower. What is your test showing? I am glad at least we figured it out. I guess we could agree on some test data and compile it into testmd5.c instead of using stdin and then we can make sure the md5 is correct on the diff arch and 64bit vs 32bit? -leif 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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects?
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
odd, just checked with your same chars pasted into the test app: jsdf;kljasdf asdf sun sparc 64 (no change to header) dc0778f4e49bd14622a016e705cbdb15 changed header: 0988915eac85ce5fed09f29252b0cc7f sun sparc 32 bit (no header change) 0988915eac85ce5fed09f29252b0cc7f linux 32 bit adb3013a42bdec7987a807bc750b47d5 linux 32 bit md5sum command on file with only the 2 lines plus the blank line: adb3013a42bdec7987a807bc750b47d5 I would say this askes the question is any md5 value we are getting from other archs valid? what did you get from your alpha for the sum? I guess this needs to be a str array to make sure.. I will write it up. thx. Thanks, Leif well that makes sence. I belive solaris figures out the uint32 as it is really emulating 32bits on the 64bit kernel. I did some reading and it seems that dbmail as a whole may not benifit much from accualy being compiled 64bit, in fact it may make it slower. What is your test showing? I am glad at least we figured it out. I guess we could agree on some test data and compile it into testmd5.c instead of using stdin and then we can make sure the md5 is correct on the diff arch and 64bit vs 32bit? -leif 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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
I'm getting the adb... on both the Opteron and my Pentium, both with typedef unsigned int uint32 So I wonder if we have an endianness issue, too... I've got a Sparc at school, I'll give it a whirl on that machine, too. And my Alpha is out of reach again, so I can't double check the results on it :-( Aaron Leif Jackson [EMAIL PROTECTED] said: odd, just checked with your same chars pasted into the test app: jsdf;kljasdf asdf sun sparc 64 (no change to header) dc0778f4e49bd14622a016e705cbdb15 changed header: 0988915eac85ce5fed09f29252b0cc7f sun sparc 32 bit (no header change) 0988915eac85ce5fed09f29252b0cc7f linux 32 bit adb3013a42bdec7987a807bc750b47d5 linux 32 bit md5sum command on file with only the 2 lines plus the blank line: adb3013a42bdec7987a807bc750b47d5 I would say this askes the question is any md5 value we are getting from other archs valid? what did you get from your alpha for the sum? I guess this needs to be a str array to make sure.. I will write it up. thx. Thanks, Leif well that makes sence. I belive solaris figures out the uint32 as it is really emulating 32bits on the 64bit kernel. I did some reading and it seems that dbmail as a whole may not benifit much from accualy being compiled 64bit, in fact it may make it slower. What is your test showing? I am glad at least we figured it out. I guess we could agree on some test data and compile it into testmd5.c instead of using stdin and then we can make sure the md5 is correct on the diff arch and 64bit vs 32bit? -leif 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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
The answer is simple... the tags BYTE_ORDER are not specified on sparc because sparc doesn't have endian.h, simple fix add to md5.h #ifdef __sparc #define LITTLE_ENDIAN 1234 #define BIG_ENDIAN4321 #define BYTE_ORDER BIG_ENDIAN #endif and them it works perfectly I get adaXXX on both 64bit and 32bit binaries! you were right we had an endian problem, it just wasn't doing the code from md5.c that was there to fix the endian problem. :) Thanks, Leif I'm getting the adb... on both the Opteron and my Pentium, both with typedef unsigned int uint32 So I wonder if we have an endianness issue, too... I've got a Sparc at school, I'll give it a whirl on that machine, too. And my Alpha is out of reach again, so I can't double check the results on it :-( Aaron Leif Jackson [EMAIL PROTECTED] said: odd, just checked with your same chars pasted into the test app: jsdf;kljasdf asdf sun sparc 64 (no change to header) dc0778f4e49bd14622a016e705cbdb15 changed header: 0988915eac85ce5fed09f29252b0cc7f sun sparc 32 bit (no header change) 0988915eac85ce5fed09f29252b0cc7f linux 32 bit adb3013a42bdec7987a807bc750b47d5 linux 32 bit md5sum command on file with only the 2 lines plus the blank line: adb3013a42bdec7987a807bc750b47d5 I would say this askes the question is any md5 value we are getting from other archs valid? what did you get from your alpha for the sum? I guess this needs to be a str array to make sure.. I will write it up. thx. Thanks, Leif well that makes sence. I belive solaris figures out the uint32 as it is really emulating 32bits on the 64bit kernel. I did some reading and it seems that dbmail as a whole may not benifit much from accualy being compiled 64bit, in fact it may make it slower. What is your test showing? I am glad at least we figured it out. I guess we could agree on some test data and compile it into testmd5.c instead of using stdin and then we can make sure the md5 is correct on the diff arch and 64bit vs 32bit? -leif 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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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 works properly on my Pentium. Just one problem: what tools can I use to debug this thing on Opteron!? I've attached my test program. It compiles in the dbmail build tree, like so: gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o Aaron
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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 Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf asdf b3dd95bad20e039aa898a75cdab51a4d Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Leif Jackson [EMAIL PROTECTED] said: 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 works properly on my Pentium. Just one problem: what tools can I use to debug this thing on Opteron!? I've attached my test program. It compiles in the dbmail build tree, like so: gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o Aaron ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev --
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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 parameter `argc' testmd5.c:58: warning: unused parameter `argv' bash-2.05$ bash-2.05$ file testmd5 testmd5:ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped bash-2.05$ ./testmd5 asdlkjaskdfj asdkfj bd800d96270606bca89656c9df095f2f bash-2.05$ I wonder if this is an optomising thing try it without opt, also is there the -m32 options for gcc on that platform to force 32bit? -leif 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it works just find. -leif [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf asdf b3dd95bad20e039aa898a75cdab51a4d Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Leif Jackson [EMAIL PROTECTED] said: 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 works properly on my Pentium. Just one problem: what tools can I use to debug this thing on Opteron!? I've attached my test program. It compiles in the dbmail build tree, like so: gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o Aaron ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it works just find. -leif [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf asdf b3dd95bad20e039aa898a75cdab51a4d Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Leif Jackson [EMAIL PROTECTED] said: 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 works properly on my Pentium. Just one problem: what tools can I use to debug this thing on Opteron!? I've attached my test program. It compiles in the dbmail build tree, like so: gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o Aaron ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev --
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it works just find. -leif [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf asdf b3dd95bad20e039aa898a75cdab51a4d Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Leif Jackson [EMAIL PROTECTED] said: 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 works properly on my Pentium. Just one problem: what tools can I use to debug this thing on Opteron!? I've attached my test program. It compiles in the dbmail build tree, like so: gcc -g -O -I. -o testmd5 testmd5.c header.o dbmd5.o md5.o debug.o Aaron ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev -- ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
Re: [Dbmail-dev] MD5 bug reproduced on Opteron
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 crashing but still giving wrong results? Being a big endian machine, there is an additional byte order reversing routine that kicks in on the Sparc; perhaps the side effect of which is not crashing? Also, clearly, we now know why my Alpha produced proper results... it was already hacked to work ;-) The correct way to handle this is with a sizeof test from configure, and an appropriate entry in config.h to give hints to word-size sensitive code. I'll make the appropriate changes this weekend :-) Aaron Aaron Stone [EMAIL PROTECTED] said: Works in 32 bit mode. Also, the resulting md5 is different... There are a couple of compiler warnings in header.c regarding size_t arguments to printf; basically, there's a different size_t size in effect, and of course a different pointer size, too. So either GCC is generating faulty 64-bit code on the Opteron, or there's just a simple 64-bit-unclean portion of the md5 code that isn't generating any warnings but sure is mucking up the output. Aaron [EMAIL PROTECTED]:~/dbmail-2.0rc3 gcc -g -O2 -I . -m32 -o testmd5 testmd5.c *o [EMAIL PROTECTED]:~/dbmail-2.0rc3 file *o testmd5 dbmd5.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped debug.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped header.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped md5.o:ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped testmd5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~/dbmail-2.0rc3 ./testmd5 ;lkajsdf;kljasdf asdf 0a8c8e4fd15849ec600d9aac8e53bf93 [EMAIL PROTECTED]:~/dbmail-2.0rc3 Leif Jackson [EMAIL PROTECTED] said: 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: 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, AMD x86-64, version 1 (SYSV), not stripped md5.o:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV), not stripped testmd5: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped Leif Jackson [EMAIL PROTECTED] said: 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: Make sence on valgrind... hey does the gcc on an operton default to a 64bit linking or do you have to do something like -64 for all the objects? I am thinking about sun and gcc for example where you cannot compile 64 bit without explicity telling the linker to link the 64 bit libs. Just a thought I know sun solaris is totaly diffrent than linux on operton. If it is accessing a 64bit NULL value, but only after completing the output from md5. very odd... I will check this on a sun after compiling 64bit. will let you know in a sec. on sun 32bit it works just find. -leif [EMAIL PROTECTED]:~/gdb-6.0 ./gdb/gdb GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. (gdb) file ../dbmail-2.0rc3/testmd5 Reading symbols from ../dbmail-2.0rc3/testmd5...done. (gdb) run Starting program: /home/users/s/so/sodabrew/dbmail-2.0rc3/testmd5 ;lkajsdf;kljasdf asdf b3dd95bad20e039aa898a75cdab51a4d Program received signal SIGSEGV, Segmentation fault. 0x in ?? () Leif Jackson [EMAIL PROTECTED] said: 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
