Claws-Mail: Lesen von Mails nur per ssh; kaputte X-lib?

Columbo0815

Kaffeemann
Staff member
Moin,

seit ein paar Wochen kann ich auf meinem FreeBSD-10.0/amd64 Rechner keine Mails in Claws-Mail mehr lesen. Wenn ich Claws-Mail starte, ist alles wie gewohnt. Sobald ich jedoch eine Mail auswähle, core-cumped Claws-Mail. Da ich mir häufig von einem anderem PC per "ssh -Y" Claws-Mail auf meinen Bildschirm hole, ist mir natürlich irgendwann aufgefallen, dass das auf dem anderen PC nicht passiert. Starte ich nun claws-mail auf dem betroffenen Rechner in einer ssh-session auf localhost, funktioniert claws-mail ebenfalls.

Ich vermute, dass sich mein Problem gar nicht mal um Claws-Mail dreht.Ich tippe vielmehr auf eine kaputte Lib von X oder dergleichen. Nur wo kann ich ansetzen?

Viele Grüße
 
Mach mal vielleicht
Code:
ulimit -c unlimited
Dann hast Du mit Glück einen Coredump, den Du mit gdb und dem Befehl "bt" (gibt einen Stacktrace aus) näher untersuchen kannst.
 
Die Ausgabe wenn ich gdb direkt aufrufe ist
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80e406400 (LWP 100229/claws-mail)]
0x00000008076731e0 in strcoll_l () from /lib/libc.so.7
(gdb)

Wenn ich danach bt eingebe kommt
#0 0x00000008076731e0 in strcoll_l () from /lib/libc.so.7
#1 0x0000000804aec4b9 in g_utf8_collate ()
from /usr/local/lib/libglib-2.0.so.0
#2 0x000000000058a7bf in vcard_read_data ()
#3 0x0000000000573e8f in addrindex_get_picture_file ()
#4 0x00000000005514a5 in textview_get_selection_offsets ()
#5 0x0000000000550060 in textview_get_selection_offsets ()
#6 0x000000000054cb77 in textview_show_part ()
#7 0x00000000004cce32 in mimeview_select_mimepart_icon ()
#8 0x00000000004ca1c6 in mimeview_create ()
#9 0x000000080483057a in _g_closure_invoke_va ()
from /usr/local/lib/libgobject-2.0.so.0
#10 0x0000000804845361 in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.0
#11 0x0000000804845d84 in g_signal_emit ()
from /usr/local/lib/libgobject-2.0.so.0
#12 0x0000000801aa771d in gtk_tree_selection_select_path ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#13 0x0000000801aa79a3 in gtk_tree_selection_select_iter ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#14 0x00000000004cd505 in mimeview_unregister_viewer_factory ()
#15 0x00000000004c0562 in messageview_show ()
#16 0x000000000054115d in summary_display_msg_selected ()
#17 0x0000000000548e57 in summaryview_unlock ()
#18 0x0000000804830311 in g_closure_invoke ()
from /usr/local/lib/libgobject-2.0.so.0
#19 0x00000008048449aa in g_signal_emitv ()
from /usr/local/lib/libgobject-2.0.so.0
#20 0x0000000804845695 in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.0
#21 0x0000000804845e82 in g_signal_emit_by_name ()
from /usr/local/lib/libgobject-2.0.so.0
#22 0x00000000005dc1e6 in gtk_sctree_select ()
#23 0x00000000005df762 in gtk_sctree_set_column_tooltip ()
#24 0x00000008019bb830 in _gtk_marshal_BOOLEAN__BOXED ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#25 0x0000000804830311 in g_closure_invoke ()
from /usr/local/lib/libgobject-2.0.so.0
#26 0x0000000804844b33 in g_signal_emitv ()
from /usr/local/lib/libgobject-2.0.so.0
#27 0x000000080484571a in g_signal_emit_valist ()
from /usr/local/lib/libgobject-2.0.so.0
#28 0x0000000804845d84 in g_signal_emit ()
from /usr/local/lib/libgobject-2.0.so.0
#29 0x0000000801add352 in gtk_widget_event ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#30 0x00000008019b994b in gtk_propagate_event ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#31 0x00000008019b9548 in gtk_main_do_event ()
from /usr/local/lib/libgtk-x11-2.0.so.0
#32 0x0000000801f16151 in _gdk_windowing_event_data_free ()
from /usr/local/lib/libgdk-x11-2.0.so.0
#33 0x0000000804abf702 in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#34 0x0000000804abfaa3 in g_main_context_pending ()
from /usr/local/lib/libglib-2.0.so.0
#35 0x0000000804abfdcf in g_main_loop_run ()
from /usr/local/lib/libglib-2.0.so.0
#36 0x00000008019b8e7f in gtk_main () from /usr/local/lib/libgtk-x11-2.0.so.0
#37 0x00000000004a78ac in main ()

Was sollte mir das jetzt sagen? :)
 
Das sieht mehr nach "Spass mit encodings" aus. Vergleich doch mal die Ausgaben von "locale" auf den entsprechenden Kisten.
 
Geht nicht: de_DE.UTF-8
Geht: de_DE.ISO8859-1

Warum nutzt das System zwei verschiedene locale (je nachdem ob ich lokal oder per ssh eingeloggt bin)?!
 
Das sieht nach einem Bug in Claws-Mail aus und zwar im vcard-Plugin. Ich nehme mal an, dass die E-Mail eine VCard fürs Adressbuch hat, welche falsch dekodiert wird. Es wäre eine gute Idee, die VCard mal an die Entwickler zu übergeben (falls nicht vertraulich).

Vorher natürlich das ganze überprüfen was ich gesagt habe. Es ist immer noch eine Vermutung.
 
nakal du hattest Recht. Es war eine vcard schuld, die ich (zumindest nicht, dass ich mich erinnere) nicht angelegt habe. Blöderweise habe ich sie einfach nur gelöscht ohne vorher zu sichern. Jetzt läuft zwar claws-mail wieder, ich kann die vcard aber nicht zur Verfügung stellen, da gelöscht.

Nunja.. Danke (auch an #claws), die ebenfalls sagten, dass es eine vcard ist.
 
Der Fehler ist reproduzierbar: Im Adressbuch eine vcard mit utf-8 erstellen: Claws-Mail schmiert ab. vcard mit ISO8859-1 erstellen: Claws-Mail schmiert nicht ab.

Wenn ich - nachdem ich die vcard mit ISO8859-1 erstellt habe eine Mail lesen möchte und claws-mail mit utf-8 starte, schmiert claws-mail wieder ab.
 
Was genau ist claws schuld, wenn Du ihm kaputte Daten gibst?

Wenn ich mich nicht täusche, sollte laut RFC6350 Section 3.1 UTF-8 korrekt sein:
RFC6350 said:
The charset (see [RFC3536] for internationalization terminology) for vCard is UTF-8 as defined in [RFC3629]. There is no way to override this. It is invalid to specify a value other than "UTF-8" in the "charset" MIME parameter (see Section 10.1).
 
Der Fehler ist reproduzierbar: Im Adressbuch eine vcard mit utf-8 erstellen: Claws-Mail schmiert ab. vcard mit ISO8859-1 erstellen: Claws-Mail schmiert nicht ab.

Wenn ich - nachdem ich die vcard mit ISO8859-1 erstellt habe eine Mail lesen möchte und claws-mail mit utf-8 starte, schmiert claws-mail wieder ab.

Könntest mal versuchen, ob solch ein Eintrag in die ~/.profile hilft:
Code:
G_FILENAME_ENCODING=UTF-8; export G_FILENAME_ENCODING
Das sollte dann diese Umgebungsvariable geben:
Code:
env | grep G_FILENAME

G_FILENAME_ENCODING=UTF-8
 
Könntest mal versuchen, ob solch ein Eintrag in die ~/.profile hilft:
Code:
G_FILENAME_ENCODING=UTF-8; export G_FILENAME_ENCODING
Das sollte dann diese Umgebungsvariable geben:
Code:
env | grep G_FILENAME

G_FILENAME_ENCODING=UTF-8
Habe ich gemacht. Sobald ich mit claws-mail und UTF-8 eine vcard erstelle, schmiert mir claws-mail ab. Also keine Änderung.

Danke und Gruß
 
Ich habe nichts besonderes eingestellt, es sollte also default sein. Anders gesagt: Wie finde ich das raus?
 
???
ohne ssh:
$ locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_ALL=

mit ssh:
$ locale
LANG=de_DE.ISO8859-1
LC_CTYPE="de_DE.ISO8859-1"
LC_COLLATE="de_DE.ISO8859-1"
LC_TIME="de_DE.ISO8859-1"
LC_NUMERIC="de_DE.ISO8859-1"
LC_MONETARY="de_DE.ISO8859-1"
LC_MESSAGES="de_DE.ISO8859-1"
LC_ALL=
 
Fragen:
1) Macht sylpheed das auch so?
2) Wenn Du es dringend brauchst, warum steigst Du nicht wieder auf 8859-1 um?
3) Was sagen die Claws-Jungs zu dem Problem?
 
1. Keine Ahnung, ich nutze sylpheed nicht. Teste ich aber bei Gelegenheit.
2. Ich brauche es nicht dringend. Ich brauche es gar nicht. Anfänglich war mir der Grund für den Absturz nicht bekannt. Dieser hat sich erst durch die Mithilfe hier im Forum/IRC gezeigt. Warum das jetzt immer noch thematisiert wird (zumindest von meiner Seite): Die Ursache des Fehlers. Vielleicht ist nicht claws-mail schuld sondern FreeBSD? Ich gehe davon aus, dass zB Fusselbär das auch so verstanden hat: Das Problem ist (für mich) gelöst. Wenn die Ursache gefunden ist, kann man es an die betroffene Stelle melden.
3. Die sagen "gib mir mal die kaputte vcard" und "oh, die wird ja gar nicht erstellt, also kannst du sie uns nicht geben".

:)
 
Back
Top