3.6p2 build errors on buffer_get with latest portable/SNAP

[STEWARD, Curtis (Jamestown)]

Ok, this is what I did:

  1)  I reinstalled psyche (8.0) w/3.7p1 - no problems with OpenSSH.
  2)  Put on 3.7p1 on a vm (VMWare) - no problems with OpenSSH.
  3)  Put on my usual config onto vm - no problems with OpenSSH.
  4)  At this point I can only assume the other two examples
fail because of some bogus configuration that I can't duplicate...  
Anyways I proceeded in forcing the core dump and received a
memory access error on the old machine:

# gdb -q ./sshd core.27823
Core was generated by `./sshd -t'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libcrypto.so.2...done.
Loaded symbols for /lib/libcrypto.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x42028ac8 in raise () from /lib/i686/libc.so.6
#2  0x4202a019 in abort () from /lib/i686/libc.so.6
#3  0x080688b2 in buffer_get ()
Cannot access memory at address 0x3
(gdb)

It looks like I can run now despite the above, if you want 
to continue to pursue the memory problem let me know, I'll 
hang onto the problematic machine :)

cs

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au]
Sent: Thursday, September 11, 2003 9:31 PM
To: STEWARD, Curtis (Jamestown)
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: 3.6p2 build errors on buffer_get with latest portable/SNAP


"STEWARD, Curtis (Jamestown)" wrote:
> I'm new to some of this so bear with me, I did post a
> buffer_get() error but while debugging I could make it fail
> on buffer_init() 31, weird.  Here's the bt without
> the continue:

> (gdb) bt
> #0  buffer_get (buffer=0xbffff210, buf=0x0, len=1) at buffer.c:124
> #1  0x00000000 in ?? ()

Hmm, there should be more here, I don't know what there isn't.

Plan B: if you insert an abort(); immediately before the fatal at
buffer.c:124 then run it normally, you should get a core dump which you
can generate the backtrace from.  It should look something like this:

# ./sshd -t
[core dumps]
# gdb -q ./sshd core
Core was generated by `./sshd -t'.
[snip]
#0  0x4020bfd1 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x4020bfd1 in kill () from /lib/libc.so.6
#1  0x4020bc94 in raise () from /lib/libc.so.6
#2  0x4020d04d in abort () from /lib/libc.so.6
#3  0x08062bd7 in buffer_get () at ../buffer.c:123
#4  0x08062a1c in buffer_get_char (buffer=0xbfffd4f0) at ../bufaux.c:262
#5  0x08061ac5 in key_load_public_rsa1 (fd=3,
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key", commentp=0x0)
    at ../authfile.c:268
#6  0x080622f3 in key_load_private (
    filename=0x8079e80 "/usr/local/etc/ssh_host_rsa_key",
    passphrase=0x8078c1a "", commentp=0x0) at ../authfile.c:573
#7  0x0804d8ae in main (ac=2, av=0x8092f68) at ../sshd.c:978
#8  0x401fa4ed in __libc_start_main () from /lib/libc.so.6

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.