Re: Programme hängen beim Zugriff auf CIFS-Mount

Hallo,

das neblige Wetter bietet eine gute Gelegenheit, einen Thread vom
letzten Jahr bei nebligem Wetter noch einmal auszugraben, da sich das
Problem leider immer noch nicht erledigt hat: ;)

Am 24.11.2015 um 09:17 schrieb Alexander Klein:

> ich habe immer mal wieder Probleme beim Bearbeiten von Dateien auf einem
> CIFS-Mount. Konkret äußert sich die Sache darin, daß beispielsweise vi
> oder auch lowriter sich beim Öffnen oder Schreiben einer Datei
> verklemmen und sämtliche verfügbare CPU-Zeit verbrauchen.
>
> Wenn ich truss auf die verklemmten Prozesse ansetze, dann bekomme ich
> eine Flut von Meldungen folgender Art:
>
> open("�A�($ѿ�(ѿ�.db",O_CLOEXEC,00) = 5 (0x5)

Ich bin jetzt endlich einmal dazu gekommen, mir die Sache näher
anzusehen, habe nvi mit -g übersetzt und mal einen Debugger dran
gehängt, der mir bei dem Hänger folgenden Backtrace liefert:

#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

Das entsprechende Stück nvi-Quelle ist recht unspektakulär:

119 rval = editor(gp, argc, argv);
120

121 /* Clean up signals. */
122 sig_end(gp);
123
124 /* Clean up the terminal. */

125 (void)cl_quit(gp);
126
127 /*
128 * XXX

Das Problem scheint also in der libc zu liegen, die in _openat hängen
bleibt, und ich habe nun auch die libc mit -g übersetzt.

Die Frage ist jetzt nur: Wie weiter?

Ich würde gerne mein (n)vi mit Debug-Symbolen gegen die libc mit
Debug-Symbolen linken, es dabei jedoch am liebsten vermeiden, libc für
das ganze System auszutauschen. Mein letzter Versuch, die libc für das
ganze System zu tauschen war vor etwa fünfzehn Jahren unter Linux und
ist böse daneben gegangen. ;)

Ich habe also Folgendes versucht:

- Die neue libc nach /tmp/libc-debug/usr/lib installiert,

- vi neu gebaut mit LD=-L/tmp/libc-debug/usr/lib/

- vi gestartet und in einem anderen Fenster gdb,

- gdb über die Symbole informiert:

   + add-symbol-file /usr/src/usr.bin/vi/nvi
   + add-symbol-file /usr/src/lib/libc/libc.so

- gdb drangehängt und eine komische Fehlermeldung bekommen:

   attach 4463
Attaching to process 4463
/usr/src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/solib-svr4.c:1444:
internal-error: legacy_fetch_link_map_offsets called without legacy
link_map support enabled.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

- Als vi wieder hing, den gdb mit Ctrl+C unterbrochen, was dann
folgenden Stacktrace lieferte:

(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 ?? ()

Die Frage ist jetzt, ob letztere Ausgabe nach der Fehlermeldung von gdb
überhaupt sinnvoll ist, und ob es nicht besser wäre, einen Bugreport für
libc zu verfassen, damit sich Leute damit befassen, die sich besser
auskennen.

Gibt es an dieser Stelle noch irgend etwas Sinnvolles, das ich ohne
tiefere Kenntnisse über die Interna des Systems tun kann?

Viele Grüße,

        Alexander

-- 
Alexander Klein
Physiologisches Institut der JLU-Gießen
Aulweg 129
35392 Gießen
http://www.med.uni-giessen.de/physio/
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message