[Bug 202419] Opening files hangs calling openat() while CWD is on a smbfs mount

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202419

Alexander Klein <alexander.klein at physiologie.med.uni-giessen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexander.klein at physiologie
                   |                            |.med.uni-giessen.de

--- Comment #1 from Alexander Klein <alexander.klein at 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.