From owner-freebsd-current@FreeBSD.ORG Tue Nov 23 17:19:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EDA516A4CE for ; Tue, 23 Nov 2004 17:19:57 +0000 (GMT) Received: from mail.evip.pl (mail.evip.com.pl [212.244.157.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1145F43D2F for ; Tue, 23 Nov 2004 17:19:56 +0000 (GMT) (envelope-from w@evip.pl) Received: from drwebc by mail.evip.pl with drweb-scanned (Exim 4.22) id 1CWeKV-000Dcs-Rm for current@freebsd.org; Tue, 23 Nov 2004 18:19:51 +0100 Received: from w by mail.evip.pl with local (Exim 4.22) id 1CWeKV-000Dcm-OJ for current@freebsd.org; Tue, 23 Nov 2004 18:19:51 +0100 Date: Tue, 23 Nov 2004 18:19:51 +0100 From: Wiktor Niesiobedzki To: current@freebsd.org Message-ID: <20041123171951.GG3584@mail.evip.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: Putty or libcrypto bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 17:19:57 -0000 Hi, When I try to run putty it dumps core. From what I found, it is triggered by having nss_ldap configured to use TLS (ldaps://). The backtrace is folowing w@portal:~$ putty zsh: segmentation fault (core dumped) putty w@portal:~$ gdb =putty putty.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "i386-marcel-freebsd"... Core was generated by `putty'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libgtk12.so.2...done. Loaded symbols for /usr/X11R6/lib/libgtk12.so.2 Reading symbols from /usr/X11R6/lib/libgdk12.so.2...done. Loaded symbols for /usr/X11R6/lib/libgdk12.so.2 Reading symbols from /usr/local/lib/libgmodule12.so.3...done. Loaded symbols for /usr/local/lib/libgmodule12.so.3 Reading symbols from /usr/local/lib/libglib12.so.3...done. Loaded symbols for /usr/local/lib/libglib12.so.3 Reading symbols from /usr/local/lib/libintl.so.6...done. Loaded symbols for /usr/local/lib/libintl.so.6 Reading symbols from /usr/X11R6/lib/libXi.so.6...done. Loaded symbols for /usr/X11R6/lib/libXi.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /lib/libm.so.3...done. Loaded symbols for /lib/libm.so.3 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libm.so.2...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/nss_ldap.so.1...done. Loaded symbols for /usr/local/lib/nss_ldap.so.1 Reading symbols from /usr/local/lib/libldap-2.2.so.7...done. Loaded symbols for /usr/local/lib/libldap-2.2.so.7 Reading symbols from /usr/local/lib/liblber-2.2.so.7...done. Loaded symbols for /usr/local/lib/liblber-2.2.so.7 Reading symbols from /usr/lib/libssl.so.3...done. Loaded symbols for /usr/lib/libssl.so.3 Reading symbols from /lib/libcrypto.so.3...done. Loaded symbols for /lib/libcrypto.so.3 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 Reading symbols from /lib/libc.so.5...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 sk_new (addr=0x0, port=1215526572, privport=-1077945272, oobinline=1215306875, nodelay=12, keepalive=1215450516, plug=0x80e2614) at ../unix/uxnet.c:421 421 ../unix/uxnet.c: No such file or directory. in ../unix/uxnet.c (gdb) bt #0 sk_new (addr=0x0, port=1215526572, privport=-1077945272, oobinline=1215306875, nodelay=12, keepalive=1215450516, plug=0x80e2614) at ../unix/uxnet.c:421 #1 0x487033de in sk_new_null () from /lib/libcrypto.so.3 #2 0x48701c7b in CRYPTO_set_ex_data_implementation () from /lib/libcrypto.so.3 #3 0x48701fb1 in CRYPTO_set_ex_data_implementation () from /lib/libcrypto.so.3 #4 0x48702682 in CRYPTO_get_ex_new_index () from /lib/libcrypto.so.3 #5 0x48684411 in X509_STORE_CTX_get_ex_new_index () from /lib/libcrypto.so.3 #6 0x48619dae in SSL_get_ex_data_X509_STORE_CTX_idx () from /usr/lib/libssl.so.3 #7 0x4861453d in SSL_CTX_new () from /usr/lib/libssl.so.3 #8 0x485dced3 in ldap_pvt_tls_init_def_ctx () from /usr/local/lib/libldap-2.2.so.7 #9 0x485dd400 in alloc_handle () from /usr/local/lib/libldap-2.2.so.7 #10 0x485ddc6c in ldap_int_tls_connect () from /usr/local/lib/libldap-2.2.so.7 #11 0x485dee8f in ldap_int_tls_start () from /usr/local/lib/libldap-2.2.so.7 #12 0x485bc50c in ldap_int_open_connection () from /usr/local/lib/libldap-2.2.so.7 #13 0x485ce7db in ldap_new_connection () from /usr/local/lib/libldap-2.2.so.7 #14 0x485bbe81 in ldap_open_defconn () from /usr/local/lib/libldap-2.2.so.7 #15 0x485ce297 in ldap_send_initial_request () from /usr/local/lib/libldap-2.2.so.7 #16 0x485c3167 in ldap_sasl_bind () from /usr/local/lib/libldap-2.2.so.7 #17 0x485c3ac5 in ldap_simple_bind () from /usr/local/lib/libldap-2.2.so.7 #18 0x485a1cc0 in _nss_ldap_init () from /usr/local/lib/nss_ldap.so.1 #19 0x485a1a92 in _nss_ldap_init () from /usr/local/lib/nss_ldap.so.1 #20 0x485a2bbc in _nss_ldap_search_s () from /usr/local/lib/nss_ldap.so.1 #21 0x485a3325 in _nss_ldap_getbyname () from /usr/local/lib/nss_ldap.so.1 #22 0x485a4b59 in _nss_ldap_getpwuid_r () from /usr/local/lib/nss_ldap.so.1 #23 0x483e3791 in __nss_compat_getpwuid_r () from /lib/libc.so.6 #24 0x4844c7cb in nsdispatch () from /lib/libc.so.6 #25 0x48422105 in getpwuid_r () from /lib/libc.so.6 #26 0x482b14e0 in g_get_any_init () from /usr/local/lib/libglib12.so.3 #27 0x482b1840 in g_get_home_dir () from /usr/local/lib/libglib12.so.3 #28 0x481d6ad7 in gtk_rc_append_default_module_path () from /usr/X11R6/lib/libgtk12.so.2 #29 0x481d6fc0 in gtk_rc_init () from /usr/X11R6/lib/libgtk12.so.2 #30 0x481a9042 in gtk_init_check () from /usr/X11R6/lib/libgtk12.so.2 #31 0x481a90f6 in gtk_init () from /usr/X11R6/lib/libgtk12.so.2 #32 0x08071fb5 in pt_main (argc=1, argv=0xbfbfecb4) at ../unix/pterm.c:3270 #33 0x080aad69 in main (argc=135144980, argv=0x80e2614) at ../unix/uxputty.c:140 As we may see, putty defines sk_new function and function of the same name exists in libcrypto (in /usr/src/crypto/openssl/crypto/stack/stack.c). And now my question: should the putty change the function name (what sound wired) or there should be done some magic in libcrypto, so such situations would not happen (what sounds tricky)? Cheers, Wiktor Niesiobedzki