libreport version: 2.0.10 abrt_version: 2.0.10 backtrace_rating: 4 cmdline: /usr/sbin/automount '' --pid-file /run/autofs.pid comment: I've just tried to mount a few directories from some nfs machines ... don't know when exactly this crash happened crash_function: clnt_dg_control executable: /usr/sbin/automount kernel: 3.3.4-4.fc17.x86_64 pid: 7576 pwd: / remote_result: NOTFOUND time: Po 14. květen 2012, 16:42:34 CEST uid: 0 username: root backtrace: Text file, 30727 bytes maps: Text file, 9837 bytes var_log_messages: Text file, 4460 bytes build_ids: :63651cdc0224824a9c9324c77c3b5887378e871d :5df5b54187568cf4a488586b0591dd7affab18ff :8098a3f7ba2ea61d0bd9ad887fb02b8d50fe45b8 :4555444390434459edd5379df593b6d7382f86be :6deb3812c81a54ff67dfb571ec11486ce1957e81 :9773f411dabd24c2b5c10de02179c524876abc6a :bb0595153a1f39cb52c78380f2d86afa2e5f5191 :c94e506ae611b0998870f6d191f2ee1972962309 :70c73977cdc2714f07bfb21fe3da7890a7c4c77e :822e9b3523e8312240f41a25722d539bc77ed436 :52f0c5f25b95075e6fd7682763f7c3a779a4e889 :956122ccb1c177d1b2833ae233363fbb340e5ab0 :684bbd4b413e534cd6f73db2e2ba54b5ed9c927a :9b846ce85c0a7ae220297512b7f73cba54506eff :7909c6de930371191ee0fc0b24f87a1a6df419c3 :99c50215ba8aeb2b3b5456f2e2a44b14b97a6829 :5cac642e1ae2c4487bf727104b5e1ec9d7e23662 :e6bc6e7309fb419b8f9367406701f09070db78eb :5c4f739dadc5059e12de9ba0d1d12a43d2fc86d7 :a118346229b887442f2072bbe4945bd8b981846c :c411667445e6e78a133f1a65dba6623097c303b1 cgroup: :9:perf_event:/ :8:blkio:/ :7:net_cls:/ :6:freezer:/ :5:devices:/ :4:memory:/ :3:cpuacct,cpu:/system/autofs.service :2:cpuset:/ :1:name=systemd:/system/autofs.service core_backtrace: :9b846ce85c0a7ae220297512b7f73cba54506eff 0xb2a5 - libtirpc.so.1 - :684bbd4b413e534cd6f73db2e2ba54b5ed9c927a 0x989c - lookup_hosts.so - :684bbd4b413e534cd6f73db2e2ba54b5ed9c927a 0xa01d rpc_portmap_getport lookup_hosts.so - :684bbd4b413e534cd6f73db2e2ba54b5ed9c927a 0xa65e rpc_get_exports lookup_hosts.so - :684bbd4b413e534cd6f73db2e2ba54b5ed9c927a 0x6ddc lookup_mount lookup_hosts.so - :e6bc6e7309fb419b8f9367406701f09070db78eb 0x15942 lookup_nss_mount [pie] - :e6bc6e7309fb419b8f9367406701f09070db78eb 0xd03b - [pie] - :7909c6de930371191ee0fc0b24f87a1a6df419c3 0x7d14 start_thread libpthread.so.0 - :5c4f739dadc5059e12de9ba0d1d12a43d2fc86d7 0xf194d clone libc.so.6 - dso_list: :/usr/lib64/libz.so.1.2.5 zlib-1.2.5-6.fc17.x86_64 (Fedora Project) 1335632489 :/usr/lib64/autofs/parse_sun.so autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/libxml2.so.2.7.8 libxml2-2.7.8-7.fc17.x86_64 (Fedora Project) 1335632490 :/usr/lib64/libtirpc.so.1.0.10 libtirpc-0.2.2-2.1.fc17.x86_64 (Fedora Project) 1335632648 :/usr/lib64/autofs/mount_bind.so autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/libm-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/sbin/automount autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/autofs/lookup_hosts.so autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/libgssglue.so.1.0.0 libgssglue-0.3-1.fc17.x86_64 (Fedora Project) 1335632648 :/usr/lib64/libnss_files-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/autofs/mount_nfs.so autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/libresolv-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/libnsl-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/libgcc_s-4.7.0-20120504.so.1 libgcc-4.7.0-4.fc17.x86_64 (Fedora Project) 1336390794 :/usr/lib64/autofs/lookup_file.so autofs-1:5.0.6-16.fc17.x86_64 (Fedora Project) 1336391547 :/usr/lib64/libdl-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/ld-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/libnss_dns-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/libnss_mdns4_minimal.so.2 nss-mdns-0.10-10.fc17.x86_64 (Fedora Project) 1335633563 :/usr/lib64/libc-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 :/usr/lib64/libpthread-2.15.so glibc-2.15-35.fc17.x86_64 (Fedora Project) 1336046423 environ: :SYSFONT=latarcyrheb-sun16 :PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin :PWD=/ :LANG=cs_CZ.UTF-8 :KEYTABLE=cz-lat2 :SHLVL=0 :BOOT_IMAGE=/vmlinuz-3.3.4-4.fc17.x86_64 :TIMEOUT=300 :BROWSE_MODE=no :MOUNT_NFS_DEFAULT_PROTOCOL=4 :USE_MISC_DEVICE=yes 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 unlimited unlimited bytes :Max resident set unlimited unlimited bytes :Max processes 29875 29875 processes :Max open files 10240 10240 files :Max locked memory 65536 65536 bytes :Max address space unlimited unlimited bytes :Max file locks unlimited unlimited locks :Max pending signals 29875 29875 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: 0100002 :1:/dev/null :pos: 0 :flags: 0100002 :2:/dev/null :pos: 0 :flags: 0100002 :3:/dev/autofs :pos: 0 :flags: 02100000 :4:pipe:[229730] :pos: 0 :flags: 02000000
Created attachment 584617 [details] File: backtrace
Created attachment 584618 [details] File: maps
Created attachment 584619 [details] File: var_log_messages
Mmmm ... there does appear to be an assumption in create_client() that when one of the calls to rpc_do_create_client() gets a zero return it implies the RPC client is non-null which might not be the case. As a quick check we could try a change to account for that, if your willing that is.
I was unable to duplicate this on F16, but was able to on and F17 beta install. Try this build: https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 The problem appears to be a combination of a passed stack variable being non-null and getaddrinfo(3) not returning a lookup failure on a name that obviously has no valid translation.
Created attachment 584895 [details] Patch - fix initialization in rpc create_client()
(In reply to comment #5) > Try this build: > https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 ok, installed how do I test that the problem is gone?
(In reply to comment #7) > (In reply to comment #5) > > Try this build: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=319139 > > ok, installed > > how do I test that the problem is gone? That's a good question and I don't have a good answer. The problem is I don't actually know what the root cause is but I believe it is with getaddrinfo(3), either the way it works for the call setup I use has changed or its behaviour has become broken in some way. But this same call setup has been working fine for quite a long time now. On an F17 beta install it works fine for me and I can't get it to fail other than feeding it an obviously bogus name. But for another person who reported this it appears to fail every time and the change here just prevents the SEGV when getaddrinfo(3) incorrectly fails (ie. returns success for a name lookup but returns no name records). I could detect this type of failure and attempt to use a different RPC client create function but I think that will have side effects for other autofs functionality. So I'm not sure yet what to do. Bottom line is all you for me to test is to use it for a while wait until the problem re-occurs. I'm not sure how we can get more information about the failure yet either so I'll think about that in the mean time. Ian
I think I've resolved this in another bug, see bug 821847. If you agree I'll mark this a duplicate of that bug and finish the update using that bug instead of this one.
(In reply to comment #9) > I think I've resolved this in another bug, see bug 821847. > > If you agree I'll mark this a duplicate of that bug and > finish the update using that bug instead of this one. np, as long as abrt is able to redirect (as for me, looks like I'm going to completely forget that this one exists before it crashes again ... :-))
(In reply to comment #10) > (In reply to comment #9) > > I think I've resolved this in another bug, see bug 821847. > > > > If you agree I'll mark this a duplicate of that bug and > > finish the update using that bug instead of this one. > > np, as long as abrt is able to redirect I guess we'll find out then, ;) *** This bug has been marked as a duplicate of bug 821847 ***