Date: Tue, 25 Oct 2016 06:33:54 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 202419] Opening files hangs calling openat() while CWD is on a smbfs mount Message-ID: <bug-202419-8-Lb1unsU3hh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-202419-8@https.bugs.freebsd.org/bugzilla/> References: <bug-202419-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202419 Alexander Klein <alexander.klein@physiologie.med.uni-giessen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexander.klein@physiologie | |.med.uni-giessen.de --- Comment #1 from Alexander Klein <alexander.klein@physiologie.med.uni-gi= essen.de> --- This has been a problem for me since early 2015, and it appears quite relia= bly with vi from /usr/bin, too. My SMBFS-Options are: rw,noexec,nosuid,-f=3D0666,-d=3D0777,-u=3Dnobody,-g=3Dnobody and the share is provided by Samba version 3.6.12-1.fc17 with no problems whatsoever when connecting from Linux or Windows. Truss gives me an infinite stream of identical messages like: openat(AT_FDCWD,"=EF=BF=BD.db",O_CLOEXEC,00) =3D 499 (0x1f3) Attaching gdb to the locked process produces the following backtrace: #0 0x2822b0a1 in _openat () from /lib/libc.so.7 #1 0x281d8ac8 in open () from /lib/libc.so.7 #2 0x281d6f34 in _citrus_map_file () from /lib/libc.so.7 #3 0x281d31d0 in _citrus_mapper_set_persistent () from /lib/libc.so.7 #4 0x281d33c5 in _citrus_mapper_set_persistent () from /lib/libc.so.7 #5 0x281a8951 in _citrus_lookup_factory_convert () from /lib/libc.so.7 #6 0x281a65d5 in __bsd_iconv_open () from /lib/libc.so.7 #7 0x281a6543 in __bsd_iconv_open () from /lib/libc.so.7 #8 0x08052826 in conv_enc (sp=3D0x28834a00, option=3D23, enc=3D0x288331c8 = "UTF-8") at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:405 #9 0x080520be in conv_init (orig=3D0x28834400, sp=3D0x28834a00) at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:360 #10 0x0806df71 in screen_init (gp=3D0x28803000, orig=3D0x28834400, spp=3D0x= 28803018) at /usr/src/usr.bin/vi/../../contrib/nvi/common/screen.c:118 #11 0x080a20c9 in v_ecl_init (sp=3D0x28834400) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:638 #12 0x080a1a32 in v_ecl_log (sp=3D0x28834400, tp=3D0x28862100) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:587 #13 0x080a17ec in v_ex (sp=3D0x28834400, vp=3D0xbfbfe538) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:376 #14 0x080b9174 in vi (spp=3D0xbfbfe838) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vi.c:230 #15 0x08060e23 in editor (gp=3D0x28803000, argc=3D0, argv=3D0xbfbfe954) at /usr/src/usr.bin/vi/../../contrib/nvi/common/main.c:4= 22 #16 0x0804d5e0 in main (argc=3D1, argv=3D0xbfbfe950) at /usr/src/usr.bin/vi/../../contrib/nvi/cl/cl_main.c:119 Digging deeper into the issue, I also linked vi against a temporary libc bu= ilt with debug-information, but gdb threw an error related to the format of the symbol table, so the following information may have to be taken with a grai= n of salt: (gdb) bt #0 0x2822b0a1 in ?? () #1 0x281d8ac8 in ?? () #2 0xffffff9c in ?? () #3 0xbfbfc958 in ?? () #4 0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=3D0x8, node=3D0x282d2dc0) at /usr/src/lib/libc/jemalloc_extent.c:25 #5 0x281d6f34 in ?? () #6 0xbfbfc958 in ?? () #7 0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=3D0x282d2b88, node=3D0x284000c8) at /usr/src/lib/libc/jemalloc_extent.c:25 #8 0x281d31d0 in ?? () #9 0xbfbfc950 in ?? () #10 0xbfbfc958 in ?? () #11 0x2829aac0 in ?? () #12 0xbfbfcddc in ?? () #13 0x288a700c in ?? () #14 0x080e3b30 in optarg@@FBSD_1.0 () #15 0x00000000 in ?? () --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202419-8-Lb1unsU3hh>