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. > >> > 0x0000000000000000 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 > >> >> [email protected] > >> >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> >> > >> > > >> > > >> > > >> > -- > >> > > >> > > >> > > >> > _______________________________________________ > >> > Dbmail-dev mailing list > >> > [email protected] > >> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > >> > >> _______________________________________________ > >> Dbmail-dev mailing list > >> [email protected] > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > > > > > > -- > > > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
