Mailing List Archive

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
>

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:

sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>



--

> 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


> sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>

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
>
>
>> sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>

Looks like 64 bit by default on the Opteron...

sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>
>
> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>



--

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...
>
> sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>>
>>
>> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>

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


sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
testmd5.c *o
sodabrew@amd64-linux1:~/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
sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
;lkajsdf;kljasdf
asdf

0a8c8e4fd15849ec600d9aac8e53bf93
sodabrew@amd64-linux1:~/dbmail-2.0rc3>


"Leif Jackson" <ljackson@jjcons.com> 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...
> >
> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >>
> >>
> >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

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" <aaron@serendipity.palo-alto.ca.us> 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
>
>
> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
> testmd5.c *o
> sodabrew@amd64-linux1:~/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
> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
> ;lkajsdf;kljasdf
> asdf
>
> 0a8c8e4fd15849ec600d9aac8e53bf93
> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
>
>
> "Leif Jackson" <ljackson@jjcons.com> 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...
> > >
> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> > >>
> > >>
> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> > >
> >
> > _______________________________________________
> > 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
>



--

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" <aaron@serendipity.palo-alto.ca.us> 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
>>
>>
>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
>> testmd5.c *o
>> sodabrew@amd64-linux1:~/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
>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
>> ;lkajsdf;kljasdf
>> asdf
>>
>> 0a8c8e4fd15849ec600d9aac8e53bf93
>> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
>>
>>
>> "Leif Jackson" <ljackson@jjcons.com> 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...
>> > >
>> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>> > >>
>> > >>
>> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>> > >
>> >
>> > _______________________________________________
>> > 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
>

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"" <ljackson@jjcons.com> 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" <aaron@serendipity.palo-alto.ca.us> 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
> >>
> >>
> >> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
> >> testmd5.c *o
> >> sodabrew@amd64-linux1:~/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
> >> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
> >> ;lkajsdf;kljasdf
> >> asdf
> >>
> >> 0a8c8e4fd15849ec600d9aac8e53bf93
> >> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
> >>
> >>
> >> "Leif Jackson" <ljackson@jjcons.com> 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...
> >> > >
> >> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >> > >>
> >> > >>
> >> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >> > >
> >> >
> >> > _______________________________________________
> >> > 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
>



--

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" <aaron@serendipity.palo-alto.ca.us> 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
>>>
>>>
>>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
>>> testmd5.c *o
>>> sodabrew@amd64-linux1:~/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
>>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
>>> ;lkajsdf;kljasdf
>>> asdf
>>>
>>> 0a8c8e4fd15849ec600d9aac8e53bf93
>>> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
>>>
>>>
>>> "Leif Jackson" <ljackson@jjcons.com> 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...
>>> > >
>>> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>>> > >>
>>> > >>
>>> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>>> > >
>>> >
>>> > _______________________________________________
>>> > 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
>

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"" <ljackson@jjcons.com> 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" <aaron@serendipity.palo-alto.ca.us> 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
> >>>
> >>>
> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
> >>> testmd5.c *o
> >>> sodabrew@amd64-linux1:~/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
> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
> >>> ;lkajsdf;kljasdf
> >>> asdf
> >>>
> >>> 0a8c8e4fd15849ec600d9aac8e53bf93
> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
> >>>
> >>>
> >>> "Leif Jackson" <ljackson@jjcons.com> 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...
> >>> > >
> >>> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >>> > >>
> >>> > >>
> >>> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> >>> > >
> >>> >
> >>> > _______________________________________________
> >>> > 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
> >
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

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_ENDIAN 4321
#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"" <ljackson@jjcons.com> 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" <aaron@serendipity.palo-alto.ca.us> 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
>> >>>
>> >>>
>> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o
>> testmd5
>> >>> testmd5.c *o
>> >>> sodabrew@amd64-linux1:~/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
>> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
>> >>> ;lkajsdf;kljasdf
>> >>> asdf
>> >>>
>> >>> 0a8c8e4fd15849ec600d9aac8e53bf93
>> >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
>> >>>
>> >>>
>> >>> "Leif Jackson" <ljackson@jjcons.com> 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...
>> >>> > >
>> >>> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>> >>> > >>
>> >>> > >>
>> >>> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
>> >>> > >
>> >>> >
>> >>> > _______________________________________________
>> >>> > 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
>> >
>>
>> _______________________________________________
>> 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
>

Solaris lacks endian.h, so we'll need to use something like AC_C_BIGENDIAN in
autoconf to find out what the endianness of the host platform is. There's a
known issue that gives cross compilers trouble, but I'll set up md5.c so that
endian.h is used first, otherwise the direct testing of the host.

I'll fix it all up this evening.

Aaron


""Aaron Stone"" <aaron@serendipity.palo-alto.ca.us> said:

> 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"" <ljackson@jjcons.com> 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" <aaron@serendipity.palo-alto.ca.us> 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
> > >>>
> > >>>
> > >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> gcc -g -O2 -I . -m32 -o testmd5
> > >>> testmd5.c *o
> > >>> sodabrew@amd64-linux1:~/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
> > >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3> ./testmd5
> > >>> ;lkajsdf;kljasdf
> > >>> asdf
> > >>>
> > >>> 0a8c8e4fd15849ec600d9aac8e53bf93
> > >>> sodabrew@amd64-linux1:~/dbmail-2.0rc3>
> > >>>
> > >>>
> > >>> "Leif Jackson" <ljackson@jjcons.com> 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...
> > >>> > >
> > >>> > > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> > >>> > >>
> > >>> > >>
> > >>> > >> > sodabrew@amd64-linux1:~/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"" <ljackson@jjcons.com> 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
> > >>> > >
> > >>> >
> > >>> > _______________________________________________
> > >>> > 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
> > >
> >
> > _______________________________________________
> > 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
>



--