Static build segfaults on x86_64

[Bostjan Skufca]

Thanks for the tip on building with only static instance of OpenSSL.

No core dumps were produced, and so far I was unable to get the daemon
working with gdb attached to it.
I compiled it statically as before and with --disable-strip. In
standalone (no gdb) it produces the same results.
Then the commands I execute are these:

(start the daemon)
# /usr/local/ssh/sbin/sshd

(attach the gdb to process)
# gdb /usr/local/ssh/sbin/sshd PID

Then I try to connect but the client just hangs waiting for a response
from server. If I attach to sshd process with 'strace' it works just
fine. Therefore I am unable to get to the point where I can exit the
first child, wait for the server crash and get a backtrace. Any
additional hints?

b.



2009/12/29 Darren Tucker <dtucker at zip.com.au>:
> Bostjan Skufca wrote:
>>
>> Hello everyone,
>>
>> I would like to ask you for advice on how to approach (or solve) this
>> particular problem.
>>
>> I use Slackware Linux and compile Openssh from source. I prefer to
>> compile it statically so it doesn't get messed up if I update openssl
>> libraries. Up until now this approach was working OK for me.
>
> As an aside: you don't need to statically link the whole binary just to get
> the crypto libs.  If you build OpenSSL with just the static library
> (libcrypto.a) and configure OpenSSH --with-ssl-dir=thatdir then the linker
> will pick up the crypto functions from the static library and the remainder
> from the system dynamic libraries.
>
>> Lately I have been challenged with Slackware64 installations and I
>> have come across a problem with Openssh version (5.3p1, but result is
>> the same with 5.2p1). What happens is that sshd daemon keeps accepting
>> connections as long as no one disconnects. On the first DISconnection
>> the server daemon dies with segfault message, of which a strace output
>> I have included below.
>
> Unfortunately the strace does not show anything useful, but from your
> description it sounds like it's crashing in the SIGCHLD handler, although I
> don't know why it would show up only with static linking.
>
> You might get something more useful from enabling sshd's debugging, eg
>
> # /path/to/sshd -o LogLevel=debug3 -D
>
> [...]
>>
>> How should I start solving this problem? I am proficient in PHP and
>> other Untyped languages but I am only moderately familiar with C
>> programming.
>
> Did it generate a core dump?  if so, your first step is to feed it into gdb
> and generate a backtrace, which will tell you where it crashed.  You do:
>
> $ gdb /path/to/sshd core
> (gdb) bt
>
> If it doesn't generate a core dump (eg because the ulimit prevents it) then
> you can attach gdb to the process you expect to crash, wait for it to crash
> then generate the backtrace
>
> $ gdb /path/to/sshd [pid of sshd]
> [wait for crash]
> (gdb) bt
>
> --
> 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.
>