Emacs stürzt beim Betreten einer IMAP-Gruppe ab

[Stefan Wiens]

Ich habe hier eine IMAP-Gruppe (im Group-Buffer)

2: nnimap+s_wi_gmx_net:Spamverdacht

Was dahinter steckt, könnt ihr euch vorstellen.
Neuerdings stürzt beim Versuch, die Gruppe zu
betreten, nicht nur Gnus, sondern Emacs komplett
ab.

Wie kann man den Fehler einkreisen?

Mit einem andern Mailreader dort reinzugehen,
würde vielleicht die Störung beseitigen, aber
nicht das Emacs-Problem, das vielleicht auf
einen tiefergehenden Bug hindeutet.

--
Stefan

[Stefan Wiens]

in ~/.xsession-errors äußert sich das folgendermaßen:
(Mehrere Versuche.)

,----
| (emacs:3673): GLib-WARNING **: 11:09:24.502: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
| (emacs:3673): GLib-WARNING **: 11:09:24.502: g_main_context_check() called recursively from within a source's check() or prepare() member.
| (emacs:15794): GLib-WARNING **: 11:11:34.789: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
| (emacs:15794): GLib-WARNING **: 11:11:34.789: g_main_context_check() called recursively from within a source's check() or prepare() member.
| (emacs:15825): GLib-WARNING **: 11:13:00.287: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
| (emacs:15825): GLib-WARNING **: 11:13:00.288: g_main_context_check() called recursively from within a source's check() or prepare() member.
| (emacs:15843): GLib-WARNING **: 11:15:53.084: g_main_context_prepare() called recursively from within a source's check() or prepare() member.
| (emacs:15843): GLib-WARNING **: 11:15:53.085: g_main_context_check() called recursively from within a source's check() or prepare() member.
`----

--
Stefan

[Torsten Mueller]

Stefan Wiens <s....@gmx.net> schrieb:

> Wie kann man den Fehler einkreisen?
>
> Mit einem andern Mailreader dort reinzugehen, würde vielleicht die
> Störung beseitigen, aber nicht das Emacs-Problem, das vielleicht auf
> einen tiefergehenden Bug hindeutet.

Du würdest aber zumindest dort sehen, ob das Verzeichnis in Ordnung ist
oder nicht. In Deinem anderen post taucht das Wort "recursive" auf.

Ich hab's mit Hilfe eines Webclients auch schon fertiggebracht, in einem
Verzeichnis auf einem IMAP-Server Strukturen mit unerwarteter Tiefe
anzulegen, die dann u.U. gar nicht so leicht wieder zu entfernen sind.

T.M.

[Torsten Mueller]

Stefan Wiens <s....@gmx.net> schrieb:

> Wie kann man den Fehler einkreisen?
>
> Mit einem andern Mailreader dort reinzugehen, würde vielleicht die
> Störung beseitigen, aber nicht das Emacs-Problem, das vielleicht auf
> einen tiefergehenden Bug hindeutet.

[Stefan Wiens]

Gnus bzw. Emacs sollten aber gaerade bei Daten aus dem Netz
ausreichend robust sein und nicht einfach abstürzen (das
Emacs-Fenster verschwindet einfach).

Mit dem Lisp-Debugger könnte man nur im Single-Step-Modus
bis zum Absturz gelangen, aber dei interessanten Daten
sind dann nicht mehr verfügbar.


Wenn ich mit einem anderen Client in das Verzeichnis gehe,
ändert sich beim Server vielleicht ein Detail und der Absturz
tritt nicht mehr auf, aber der Fehler in Gnus bzw. Emacs
verschwindet dadurch nicht.


Rekursive Strukturen in Artikelbäumen lassen sich trivial
erstellen und Gnus sollte nicht darüber stolpern (habe ich
länger nicht mehr getestet), geschweige denn Emacs zum
Absturz bringen.

--
Stefan

[Clemens Schüller]

Servus!

Hmm, evtl. mal den emacs mit strace in der Konsole starten und dann mit
Betreten der Gruppe einen Absturz "provozieren".

Ich denke einfach mal, dass im Spamverdacht Ordner _eine_ bestimmte Mail
mit irgendwelchen sonderbaren Zeichen dabei ist, mit der emacs/gnus
einfach nicht klarkommt.



--
LieGrü aus Graz, Clemens

[Stefan Wiens]

Der Emacs ist hier nicht selbstkompliert, sondern
Vanilla Debian Oldoldstable. Da kommt man vielleicht
nicht allzuweit; das probiere ich vielleicht mal,
wenn das Abwürgen der Emacs-Session nicht zu
ungelegen kommt.

Ich hatte auch schon den Verdacht, dass die
Installation beschädigt sein könnte,
aber dpkg -V et al. melden nichts Verdächtiges.

--
Stefan

[Stefan Wiens]

Im Terminal (hier xfce4-terminal 0.8.7.4)
stürzt Emacs beim Betreten der Gruppe nicht ab.

Ein problematisches Zeichen im *Summary*-Buffer
könnte sein:

,----
| position: 36 of 285 (12%), column: 35
| character: ⏰ (displayed as ⏰) (codepoint 9200, #o21760, #x23f0)
| preferred charset: unicode (Unicode (ISO10646))
| code point in charset: 0x23F0
| script: symbol
| syntax: . which means: punctuation
| category: .:Base
| to input: type "C-x 8 RET 23f0" or "C-x 8 RET ALARM CLOCK"
| buffer code: #xE2 #x8F #xB0
| file code: #xE2 #x8F #xB0 (encoded by coding system utf-8-unix)
| display: terminal code #xE2 #x8F #xB0
|
| Character code properties: customize what to show
| name: ALARM CLOCK
| general-category: So (Symbol, Other)
| decomposition: (9200) ('⏰')
|
| There are text properties here:
| face gnus-summary-normal-unread
| gnus-number 2663
`----

Wenn ich Pech habe, semmelt Emacs auch beim Betrachten
dieses Artikels im Grafikmodus ab.

--
Stefan

[Stefan Wiens]

So ist es!

--
Stefan

[Wolfgang Bauer]

Stefan Wiens schrieb:

Hier nicht.

Freundliche Grüße
Wolfgang
--
Die Katze ist nicht mein Gefangener,
sondern ein unabhängiges Wesen von fast gleichem Status,
das zufällig im selben Haus lebt, wie ich.
Konrad Lorenz

[Torsten Mueller]

Wolfgang Bauer <wolfgan...@mein.gmx> schrieb:

>>> Wenn ich Pech habe, semmelt Emacs auch beim Betrachten dieses
>>> Artikels im Grafikmodus ab.
>>
>> So ist es!
>
> Hier nicht.

Hier auch nicht.

T.M.

[Wolfgang Bauer]

Stefan Wiens schrieb:

> Wenn ich Pech habe, semmelt Emacs auch beim Betrachten
> dieses Artikels im Grafikmodus ab.

Mit Grafikmodus meinst Du das in der ~/.gnus.el?

(when (display-graphic-p)
(setf
gnus-sum-thread-tree-indent " "
gnus-sum-thread-tree-indent " "
gnus-sum-thread-tree-single-leaf "╰─► "
gnus-sum-thread-tree-leaf-with-other "├─► "
gnus-sum-thread-tree-vertical "│"))
(setf gnus-thread-indent-level 2)

Freundliche Grüße
Wolfgang
--
Ohne Vergangenheit und ohne Gegenwart gäbe es auch keine Zukunft.
Deshalb gilt es, die Vergangenheit zu bewahren, die Gegenwart zu leben
und die Zukunft zu gestalten.
Wolfgang Kownatka

[Stefan Wiens]

Also mit Grafikmodus meine ich X11,
(display-graphic-p) gibt dann t aus.

Unter X11 reicht schon der Versuch, das
Zeichen ALARM CLOCK einzugeben, für den
Absturz. Offenbar kein Gnus-Problem,
aber vielleicht verschwindet es nach dem
Upgrade auf Debian 11 bzw. 12. Aber da bin
ich mit einigen Bugs in XFCE unzufrieden.

--
Stefan

[Clemens Schüller]

Servus!

Stefan Wiens schrieb am 01. Nov. 2023 um 15:46:


> Unter X11 reicht schon der Versuch, das
> Zeichen ALARM CLOCK einzugeben, für den
> Absturz. Offenbar kein Gnus-Problem,
> aber vielleicht verschwindet es nach dem
> Upgrade auf Debian 11 bzw. 12. Aber da bin
> ich mit einigen Bugs in XFCE unzufrieden.

Alternativ kannst Du Dir ja mal die emacs git Sourcen[1] runterladen
und den emacs selbst bauen.



Footnotes:
[1] https://github.com/emacs-mirror/emacs.git

[Stefan Wiens]

Könnte ich. Aber ich benutze eine Distribution,
um nicht bei jedem Programm oder Tool die
Security-Updates nachverfolgen zu müssen.

de.comm.software.gnus lese ich gerade
sicherheitshalber mit emacsclient -ct.

--
Stefan

[Helmut Waitzmann]

Stefan Wiens <s....@gmx.net>:

> Unter X11 reicht schon der Versuch, das
> Zeichen ALARM CLOCK einzugeben, für den
> Absturz.
>

Ich habe gerade auf einem Emacs 26.1, der unter X11 mit
X11‐Forwarding als Grafikprogramm läuft, probiert, das Zeichen
mit Hilfe der Tastenfolge


„C-x 8 RET ALARM CLOCK“


im „*scratch*“‐Puffer einzutippen.  Das hat tadellos funktioniert
und keinen Absturz verursacht.

[Helmut Waitzmann]

Wolfgang Bauer <wolfgan...@mein.gmx>:

> Stefan Wiens schrieb:
>
>> Wenn ich Pech habe, semmelt Emacs auch beim Betrachten
>> dieses Artikels im Grafikmodus ab.
>>
>
> Mit Grafikmodus meinst Du das in der ~/.gnus.el?
>

Nein, mit Gnus hat das nicht unbedingt etwas zu tun.  Er meint
einfach nur, dass sein Emacs in einem Zustand, in dem der
Emacs‐Lisp‐Ausdruck


(display-graphic-p)


wenn man ihm den im Emacs enthaltenen Lisp‐Interpreter
zur Ausführung gibt, den Wert „t“ ergibt, ist.


Das ist der Fall, wenn der Emacs auf einem X11‐Display selber
Fenster darstellt (und nicht etwa im Gegensatz dazu, nur in einem
Terminal (oder Terminal‐Emulator) laufend, zur Ein‐ und Ausgabe
nur mit dem Terminal (‐Emulator) kommuniziert).

[Stefan Wiens]

Mit Emacsclient kann (display-graphic-p) in derselben
Emacs-Session je nach genutztem Frame ("Fenster")
sogar unterschiedliche Resultate ergeben.
Also hier unter X11 t, aus der Ferne via SSH
im Terminal nil.

--
Stefan

[Stefan Wiens]

Wenn das Zeichen anderswo für keine Probleme sorgt,
liegt es vielleicht doch an der hiesigen Installation,
auch wenn dpkg -V nichts findet. Nach dem ohnehin
fälligen dist-upgrade ist das Problem hoffentlich weg.

--
Stefan

[Stefan Wiens]

Das Problem scheint mit dem Font zusammenzuhängen.

xmessage "Hello,⏰world!" -fn "-*-courier-medium-r-normal-*-14-*-*-*-*-*-*"
zeigt hier an der fraglichen Stelle "Hello,â\217°world!"
und verrechnet sich offenbar bei der Textbreite. Das
Zeichen ist in dem zugeordneten Font wohl nicht
enthalten.

Aber wie gesagt, trotz des Emacs-Absturzes ist es
nicht so prioritär.

--
Stefan