Bug 835674 - [abrt] openvpn-2.2.2-4.fc17: __libc_res_nsend: Process /usr/sbin/openvpn was killed by signal 11 (SIGSEGV)
[abrt] openvpn-2.2.2-4.fc17: __libc_res_nsend: Process /usr/sbin/openvpn was ...
Status: CLOSED DUPLICATE of bug 835090
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
17
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
abrt_hash:a6f0e9c7cd0fe73758b45e75326...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-26 15:25 EDT by J.H.M. Dassen (Ray)
Modified: 2016-11-24 11:05 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-27 06:41:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (89.43 KB, text/plain)
2012-06-26 15:25 EDT, J.H.M. Dassen (Ray)
no flags Details
File: maps (8.50 KB, text/plain)
2012-06-26 15:25 EDT, J.H.M. Dassen (Ray)
no flags Details
File: var_log_messages (12.31 KB, text/plain)
2012-06-26 15:25 EDT, J.H.M. Dassen (Ray)
no flags Details

  None (edit)
Description J.H.M. Dassen (Ray) 2012-06-26 15:25:41 EDT
libreport version: 2.0.10
abrt_version:   2.0.10
backtrace_rating: 4
cmdline:        /usr/sbin/openvpn --remote ovpn-ams2.redhat.com --nobind --dev tun --proto tcp-client --port 443 --cipher AES-256-CBC --auth-nocache --tls-remote ovpn-ams2.redhat.com --reneg-sec 0 --syslog nm-openvpn --tun-mtu 1360 --script-security 2 --up /usr/libexec/nm-openvpn-service-openvpn-helper --up-restart --persist-key --persist-tun --management 127.0.0.1 1194 --management-query-passwords --route-noexec --ifconfig-noexec --client --auth-user-pass --ca /home/rdassen/.cert/RedHatISCA.pem
crash_function: __libc_res_nsend
executable:     /usr/sbin/openvpn
kernel:         3.4.3-1.fc17.x86_64
pid:            10417
pwd:            /
time:           Tue 26 Jun 2012 09:14:34 PM CEST
uid:            0
username:       root

backtrace:      Text file, 91579 bytes
maps:           Text file, 8699 bytes
var_log_messages: Text file, 12603 bytes

build_ids:
:f4f9ce91c43285df84177f9684a3e7f190a0aae1
:8d646f64cd4a6c19985423dfab9f8668c6af7f80
:388ccbe3b107145c43ae82205c3392aed373a832
:81e025678e84f37ff4a6970eb0a9a487bb0fbb6a
:6086bff484a49cc8b80cb714d7e83a6391394800
:ff8d78c2ca513147704d025ce84fe9304f7ef445
:822e9b3523e8312240f41a25722d539bc77ed436
:f4c064df8745dff15466d705fb049138f9a5c949
:fa9391be89f674c39e3fb68f635355dd3d358356
:6668de624a10d486a3484d5b4921f87b1e77d36c
:1a262290abc47e43b15d179c909c389831958b90
:d32cbeacfd9f41e3cd29b697dd111f44a2d9c127
:091927b7a315243a2ff0383dfca1fd2c665405bf
:894e7194203eda5fcff5445d3ce9796de60a749b
:bffbcd62e7590e0462384693e4d36fe8c6463b4a
:0c861d4584a090c315010d8e5d9ab13ceb746ae5
:5826afc35750b4addfe993bba7da51974fe51838
:db6fa3c1fefaf769cb25d78c25c24267145a9185
:535ee166aabdb98e39b6ae2a7a8876780f2b29b5
:67792c148d2b8f13f6732c9367e926c26d7376c5
:e99c86eb3485e54972f176ba34d78396596de7af

cgroup:
:9:perf_event:/
:8:blkio:/
:7:net_cls:/
:6:freezer:/
:5:devices:/
:4:memory:/
:3:cpuacct,cpu:/system/NetworkManager.service
:2:cpuset:/
:1:name=systemd:/system/NetworkManager.service

comment:
:openvpn crashed when called from the NetworkManager applet on a system behind a dual-stack router that has both an IPv4 and an IPv6 nameserver configured (through DHCP).
:
:/etc/resolv.conf looks like this:
:# Generated by NetworkManager
:domain fritz.box
:search fritz.box
:nameserver 192.168.178.1
:nameserver fd00::c225:6ff:fece:ce0e
:
:After commenting out the v6 nameserver IP, openvpn starts without problems.

core_backtrace:
:894e7194203eda5fcff5445d3ce9796de60a749b 0xad9d __libc_res_nsend libresolv.so.2 -
:894e7194203eda5fcff5445d3ce9796de60a749b 0x8bd0 __GI___libc_res_nquery libresolv.so.2 -
:894e7194203eda5fcff5445d3ce9796de60a749b 0x97aa __libc_res_nquerydomain libresolv.so.2 -

dso_list:
:/usr/sbin/openvpn openvpn-2.2.2-4.fc17.x86_64 (Fedora Project) 1340650944
:/usr/lib64/libz.so.1.2.5 zlib-1.2.5-6.fc17.x86_64 (Fedora Project) 1338541773
:/usr/lib64/libcrypto.so.1.0.0j openssl-1:1.0.0j-1.fc17.x86_64 (Fedora Project) 1338547854
:/usr/lib64/libgcc_s-4.7.0-20120507.so.1 libgcc-4.7.0-5.fc17.x86_64 (Fedora Project) 1338541738
:/usr/lib64/libssl.so.1.0.0j openssl-1:1.0.0j-1.fc17.x86_64 (Fedora Project) 1338547854
:/usr/lib64/libkrb5support.so.0.1 krb5-libs-1.10.2-2.fc17.x86_64 (Fedora Project) 1339779890
:/usr/lib64/liblzo2.so.2.0.0 lzo-2.06-2.fc17.x86_64 (Fedora Project) 1338541901
:/usr/lib64/libselinux.so.1 libselinux-2.1.10-3.fc17.x86_64 (Fedora Project) 1338541772
:/usr/lib64/libresolv-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libnss_files-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libpkcs11-helper.so.1.0.0 pkcs11-helper-1.09-2.fc17.x86_64 (Fedora Project) 1338542353
:/usr/lib64/libgssapi_krb5.so.2.2 krb5-libs-1.10.2-2.fc17.x86_64 (Fedora Project) 1339779890
:/usr/lib64/ld-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libk5crypto.so.3.1 krb5-libs-1.10.2-2.fc17.x86_64 (Fedora Project) 1339779890
:/usr/lib64/libcom_err.so.2.1 libcom_err-1.42.3-2.fc17.x86_64 (Fedora Project) 1338625899
:/usr/lib64/libdl-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libnss_dns-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libkeyutils.so.1.4 keyutils-libs-1.5.5-2.fc17.x86_64 (Fedora Project) 1338541814
:/usr/lib64/libc-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092
:/usr/lib64/libkrb5.so.3.3 krb5-libs-1.10.2-2.fc17.x86_64 (Fedora Project) 1339779890
:/usr/lib64/libpthread-2.15.so glibc-2.15-48.fc17.x86_64 (Fedora Project) 1340651092

environ:
:SYSFONT=latarcyrheb-sun16
:PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
:LANG=en_US.UTF-8
:KEYTABLE=us
:BOOT_IMAGE=/vmlinuz-3.4.3-1.fc17.x86_64
:GIO_USE_VFS=local

limits:
:Limit                     Soft Limit           Hard Limit           Units     
:Max cpu time              unlimited            unlimited            seconds   
:Max file size             unlimited            unlimited            bytes     
:Max data size             unlimited            unlimited            bytes     
:Max stack size            8388608              unlimited            bytes     
:Max core file size        0                    unlimited            bytes     
:Max resident set          unlimited            unlimited            bytes     
:Max processes             62783                62783                processes 
:Max open files            1024                 4096                 files     
:Max locked memory         65536                65536                bytes     
:Max address space         unlimited            unlimited            bytes     
:Max file locks            unlimited            unlimited            locks     
:Max pending signals       62783                62783                signals   
:Max msgqueue size         819200               819200               bytes     
:Max nice priority         0                    0                    
:Max realtime priority     0                    0                    
:Max realtime timeout      unlimited            unlimited            us        

open_fds:
:0:/dev/null
:pos:	0
:flags:	0100000
:1:socket:[17546]
:pos:	0
:flags:	02
:2:/dev/null
:pos:	0
:flags:	0100001
:3:socket:[123147]
:pos:	0
:flags:	02000002
:4:socket:[123148]
:pos:	0
:flags:	02004002
:5:socket:[124443]
:pos:	0
:flags:	02004002
:6:socket:[124444]
:pos:	0
:flags:	02
Comment 1 J.H.M. Dassen (Ray) 2012-06-26 15:25:45 EDT
Created attachment 594575 [details]
File: backtrace
Comment 2 J.H.M. Dassen (Ray) 2012-06-26 15:25:46 EDT
Created attachment 594576 [details]
File: maps
Comment 3 J.H.M. Dassen (Ray) 2012-06-26 15:25:49 EDT
Created attachment 594577 [details]
File: var_log_messages
Comment 4 David Sommerseth 2012-06-27 04:23:15 EDT
At a quick glance, this looks more like an issue in the resolver paths in glibc ... If I interpret the backtrace correctly.

getaddr_multi() in OpenVPN (socket.c:169) calls gethostbyname() which is a glibc function.  Then this happens:

gethostbyname() [nss/getXXbyYY.c:117]
-> __gethostbyname_r() [nss/getXXbyYY_r.c:256]
  -> _nss_dns_gethostbyname_r() [nss_dns/dns-host.c:273]
    -> __GI__nss_dns_gethostbyname3_r() [nss_dns/dns-host.c:197]
      -> __GI___libc_res_nsearch() [res_query.c:378]
        -> __libc_res_nquerydomain() [res_query.c:582]
          -> __GI___libc_res_nquery() [res_query.c:226]
            ->  __libc_res_nsend() [res_send.c:445]
             *SEGFAULT* when calling: memset (mempcpy(EXT(statp).nsaddrs[n]

From the backtrace I could not see that the statp pointer comes from outside glibc, and considering the syntax of gethostbyname() that shouldn't come as a surprise either.  gethostbyname() is called with a valid string which is passed through the internal glibc functions.

So, reassigning to the glibc component.  If this is wrong, feel free to send it to the right place or back to openvpn.
Comment 5 Jeff Law 2012-06-27 06:41:41 EDT

*** This bug has been marked as a duplicate of bug 835090 ***

Note You need to log in before you can comment on or make changes to this bug.