Some problems on Solaris

Steven Bakker steven at
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[64]", 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 
something useful.

  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 mailing list