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 >
