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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202419 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-giessen.de> --- This has been a problem for me since early 2015, and it appears quite reliably with vi from /usr/bin, too. My SMBFS-Options are: rw,noexec,nosuid,-f=0666,-d=0777,-u=nobody,-g=nobody 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,"�.db",O_CLOEXEC,00) = 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=0x28834a00, option=23, enc=0x288331c8 "UTF-8") at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:405 #9 0x080520be in conv_init (orig=0x28834400, sp=0x28834a00) at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:360 #10 0x0806df71 in screen_init (gp=0x28803000, orig=0x28834400, spp=0x28803018) at /usr/src/usr.bin/vi/../../contrib/nvi/common/screen.c:118 #11 0x080a20c9 in v_ecl_init (sp=0x28834400) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:638 #12 0x080a1a32 in v_ecl_log (sp=0x28834400, tp=0x28862100) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:587 #13 0x080a17ec in v_ex (sp=0x28834400, vp=0xbfbfe538) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:376 #14 0x080b9174 in vi (spp=0xbfbfe838) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vi.c:230 #15 0x08060e23 in editor (gp=0x28803000, argc=0, argv=0xbfbfe954) at /usr/src/usr.bin/vi/../../contrib/nvi/common/main.c:422 #16 0x0804d5e0 in main (argc=1, argv=0xbfbfe950) 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 built 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 grain 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=0x8, node=0x282d2dc0) at /usr/src/lib/libc/jemalloc_extent.c:25 #5 0x281d6f34 in ?? () #6 0xbfbfc958 in ?? () #7 0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=0x282d2b88, node=0x284000c8) 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 ?? () -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202419-8-Lb1unsU3hh>