Some problems on Solaris
steven at icoe.att.com
Mon Feb 15 09:40:32 CET 1999
>>>>> On Sun, 14 Feb 1999, "JS" == Jim Seymour wrote:
>>>>> On Sun, 14 Feb 1999, "TP" == Ture Palsson wrote:
JS> Wow. Deja vu all over again :-).
JS> I had posted nearly identical issues just the other day. So, to hold
JS> you until you hear from Werner...
TP> * The configure script does not pick up -lsocket and -lnsl. Easy
TP> enough to fix, just add
Same for me...
TP> * I sometimes get a bus error at cipher/md5.c:146 (the first OP(...)
TP> line in transform()). It seems that md5_write calls transform with a
TP> `buffer' argument that is not "aligned enough" to be used as an u32*.
JS> Hmmm... I wonder if what I reported is related?
I'm getting the same problem (bus error in md5.c). It is indeed an
malaligned pointer (odd, for crying out loud!) that causes the dump.
However, when I use gdb and look at the values passed to transform(),
they're different from what transform() thinks what they are. To me, that
smells like bad stack corruption, most likely caused by some buffer
Note that in various spots in the source code, arrays are defined as
"words", without any explanation as to where the "64" comes from.
"http.c" is one that caused me headaches to debug, but I found more
examples of this. Not to be pedantic, but I would still like to point out
what _I_ learned in early SE/programming classes: Any constant (literal)
value other than 0 or 1 should be declared as a symbol and referenced by
its name. I think that if you do this consistently, it should be possible
to track down the buffer overflow. It's almost certainly one piece of
code thinking a buffer is X+Y bytes while it is in fact X.
JS> As you can see, in my case the bus error is occurring in
JS> tiger_init(). But this *looks* suspiciously similar. I had told
JS> Werner I'd try to debug the problem in more depth. (Problem is: I'm
JS> not very familiar with gdb. And it's been *years* since I had to
JS> debug to this level.) Maybe with what you've given him with your
JS> report, further efforts on my part will be unnecessary. (Werner: let
JS> me know.)
Well, compiling with the "-g" flag helped a lot with getting gdb reporting
JS> I'm building on Sun Sparc Solaris 2.4 (patched), running on a Sparc
JS> IPX (with Weitek [sp?] upgrade) and GCC 2.8.1.
Ultra 1, Solaris 7, gcc 2.8.1. Same problems.
More information about the Gnupg-devel