Remmina stürzt ab

[cosinus]

Hi,

Ich nutze rel. viel und oft Remmina um v.a. unsere Windows Server zu administrieren. Seit ein paar Tagen stürzt mir Remmina einfach so ab, auch gerne wenn ich mehrere Verbindungen auf habe und die oben in Tabs dargestellt werden und ich einen davon schließe. Es kommt keine Fehlermeldung und sowohl das Fenster mit den Verbindungen als auch das Hauptfenster ist dann einfach weg, als wenn der Prozess abgeschossen wird.

Weiß jemand woran das liegen kann? Könnte man mit dmesg o.ä. was sehen? Ich benutze zu Hause dieselbe Version und hab da solche Abstürze bisher noch nicht erlebt.

Code: Alles auswählen

# dpkg -l|grep remmina
ii  remmina                                                     1.4.39+dfsg-1                            amd64        GTK+ Remote Desktop Client
ii  remmina-common                                              1.4.39+dfsg-1                            all          Common files for Remmina
ii  remmina-plugin-rdp:amd64                                    1.4.39+dfsg-1                            amd64        RDP plugin for Remmina
ii  remmina-plugin-secret:amd64                                 1.4.39+dfsg-1                            amd64        Secret plugin for Remmina
ii  remmina-plugin-vnc:amd64                                    1.4.39+dfsg-1                            amd64        VNC plugin for Remmina

[mat6937]

... Seit ein paar Tagen stürzt mir Remmina einfach so ab, ... Ich benutze zu Hause dieselbe Version und hab da solche Abstürze bisher noch nicht erlebt.

Welche Unterschiede (OS, RAM, CPUm ...) gibt es zwischen dem abstürzenden Remmina und dem Remmina (zu Hause) das nicht abstürzt?

[cosinus]

Hm, glaubst du es liegt an der Hardware?
Der im Büro ist ein ältere HP-Computer. Hier mal die Daten von Screenfetch.

Büro-PC:

Code: Alles auswählen

         _,met$$$$$gg.           root@office
      ,g$$$$$$$$$$$$$$$P.        OS: Debian  trixie
    ,g$$P""       """Y$$.".      Kernel: x86_64 Linux 6.12.13-1-siduction-amd64
   ,$$P'              `$$$.      Uptime: 2d 9h 41m
  ',$$P       ,ggs.     `$$b:    Packages: 2331
  `d$$'     ,$P"'   .    $$$     Shell: bash 5.2.37
   $$P      d$'     ,    $$P     Disk: 20T / 48T (42%)
   $$:      $$.   -    ,d$$'     CPU: Intel Core i7-4790 @ 8x 4GHz [35.0°C]
   $$\;      Y$b._   _,d$P'      RAM: 1443MiB / 15896MiB
   Y$$.    `.`"Y$$$$P"'         
   `$$b      "-.__              
    `Y$$                        
     `Y$$.                      
       `$$b.                    
         `Y$$b.                 
            `"Y$b._             
                `""""           

Mein PC Zuhause:

Code: Alles auswählen

         _,met$$$$$gg.           root@home
      ,g$$$$$$$$$$$$$$$P.        OS: Debian  trixie
    ,g$$P""       """Y$$.".      Kernel: x86_64 Linux 6.12.13-1-siduction-amd64
   ,$$P'              `$$$.      Uptime: 1d 20m
  ',$$P       ,ggs.     `$$b:    Packages: 2289
  `d$$'     ,$P"'   .    $$$     Shell: bash 5.2.37
   $$P      d$'     ,    $$P     Disk: 555G / 1,8T (33%)
   $$:      $$.   -    ,d$$'     CPU: Intel Core i5-7400T @ 4x 3GHz [47.0°C]
   $$\;      Y$b._   _,d$P'      RAM: 5910MiB / 15894MiB
   Y$$.    `.`"Y$$$$P"'         
   `$$b      "-.__              
    `Y$$                        
     `Y$$.                      
       `$$b.                    
         `Y$$b.                 
            `"Y$b._             
                `""""           

[mat6937]

Hm, glaubst du es liegt an der Hardware?

Ich weiß es nicht. Auch bei ausreichend RAM könnte (je nach Konfiguration) ein OOM-Killer mal zuschlagen. Evtl. mit top/htop bzw. mit

Code: Alles auswählen

sysctl -a | grep -i oom
systemctl status systemd-oomd

beobachten/nachschauen.

[cosinus]

Danke, ich schau morgen mal damit nach.

[cosinus]

So, bin jetzt seit ner guten Stunde im Büro und remmina hat sich eben wieder verabschiedet. Aber dieses Mal hab ich was in dmesg gefunden:

Code: Alles auswählen

[ 1117.531450] show_signal_msg: 10 callbacks suppressed
[ 1117.531462] RemmRDP:000dehb[5518]: segfault at 20900000001 ip 00007f48b7864307 sp 00007f4891ffc178 error 4 in libc.so.6[167307,7f48b7725000+165000] likely on CPU 0 (core 0, socket 0)
[ 1117.531497] Code: 48 01 d0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 c4 41 01 ef ff 89 f8 09 f0 c1 e0 14 3d 00 00 00 f8 0f 87 29 03 00 00 <c5> fe 6f 07 c5 fd 74 0e c5 85 74 d0 c5 ed df c9 c5 fd d7 c9 ff c1

Ich werd mal bei Gelegenheit nen Memtest machen.

[king-crash]

Du kannst Software bei Problemen mit gdb starten. Der hält bei Segfaults etc einfach an und zeigt noch gewisse Infos.

[MSfree]

Du kannst Software bei Problemen mit gdb starten.

Einfacher ist es, das Programm in einem Terminal zu starten, in dem man

Code: Alles auswählen

ulimit -c 1000000

eingibt, bevor man das Programm startet. Das bewirkt, daß ein (max 1GB großer) Coredump des abgestürzten Programms geschrieben wird, den man nachträglich mit gdb analysieren kann.

Allzuviel würde ich mir davon aber nicht versprechen. Die installierten Programme haben keine Debug-Informationen mehr und wurden auch nicht spezifisch zum Debuggen kompiliert. Man kann also keine Variablenwerte anschauen. Mit Glück bekommt man einen halbwegs sinnvollen Stacktrace.

OK, man könnte das ganze im Disassambler ansehen, aber das ist nur was für Experten, die des Machinecodes mächtig sind.

[king-crash]

Mit Glück bekommt man einen halbwegs sinnvollen Stacktrace.

Wenn du nicht gerade Entwickler bist ist alles weitere auch overkill. Aber ohne einen Anhaltspunkt bringt einen der Trace oft auf die richtige Spur.

[cosinus]

Maschinencode kann ich nicht lesen.
Aus dem Terminal gestartet bringt remmina das als output, wenn es abkachelt:

Code: Alles auswählen

(org.remmina.Remmina:15689): Gtk-WARNING **: 11:06:41.316: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
[11:06:46:214] [15689:00003d94] [WARN][com.freerdp.crypto] - [verify_cb]: Certificate verification failure 'self-signed certificate (18)' at stack position 0
[11:06:46:215] [15689:00003d94] [WARN][com.freerdp.crypto] - [verify_cb]: CN = windowskiste.mydom.local
[11:06:51:231] [15689:00003d94] [WARN][com.freerdp.core.connection] - [rdp_client_connect_auto_detect]: expected messageChannelId=1008, got 1003
[11:06:51:231] [15689:00003d94] [WARN][com.freerdp.core.license] - [license_read_binary_blob_data]: license binary blob::type BB_ERROR_BLOB, length=0, skipping.
[11:06:51:343] [15689:00003d94] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Local framebuffer format  PIXEL_FORMAT_BGRX32
[11:06:51:343] [15689:00003d94] [INFO][com.freerdp.gdi] - [gdi_init_ex]: Remote framebuffer format PIXEL_FORMAT_RGB16
[11:06:51:347] [15689:00003d94] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [static] Loaded fake backend for rdpsnd
[11:06:51:347] [15689:00003d94] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel disp
[11:06:51:347] [15689:00003d94] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel ainput
[11:06:51:347] [15689:00003d94] [INFO][com.freerdp.channels.drdynvc.client] - [dvcman_load_addin]: Loading Dynamic Virtual Channel rdpsnd
[11:06:52:605] [15689:00003daa] [INFO][com.freerdp.channels.rdpsnd.client] - [rdpsnd_load_device_plugin]: [dynamic] Loaded fake backend for rdpsnd
[11:06:52:831] [15689:00003daa] [WARN][com.freerdp.channels.drdynvc.client] - [check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:10} OnOpen=(nil), OnClose=0x7f939a6af6f0
Speicherzugriffsfehler

edit: eben kam noch das beim nächsten Absturz

Code: Alles auswählen

[11:10:25:668] [15964:00003edb] [WARN][com.freerdp.channels.drdynvc.client] - [check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:9} OnOpen=(nil), OnClose=0x7ffa5c2c66f0
double free or corruption (!prev)

[MSfree]

Bekommst du einen Coredump, wenn du, wie oben gezeigt, das ulimit für Coredumps auf Nicht-Null setzt?

Der Speicherzugriffsfehler, der dir hier angezeigt wird, korrespondiert mit dem Segfault weiter oben.

Einige DE-Bibliotheken (Qt und GTK) scheinen SigSeg (das Segfault Signal) abzufangen und dann mit einem exit() auszusteigen. Das verhindert blöderweise einen Coredump, egal was man mit ulimit einstellt. Hier hilft aber der Debugger auch nicht viel weiter.

[cosinus]

Wo wird das coredump denn hingeschrieben? Hab das noch nie gemacht.

[mat6937]

Wo wird das coredump denn hingeschrieben?

Schau mal im:

Code: Alles auswählen

ls -la /var/lib/systemd/coredump

nach.

[MSfree]

Wo wird das coredump denn hingeschrieben? Hab das noch nie gemacht.

In das aktuelle Verzeichnis. Du mußt remina natürlich auch aus dem Terminal starten.

[cosinus]

Hab ich doch gemacht.

Code: Alles auswählen

-rw-------  1 cosinus cosinus 399M 2025-02-17 12:29 core.29727
-rw-------  1 cosinus cosinus 211M 2025-02-17 12:32 core.30161

Die Dumps sind aber sehr groß. Wonach soll ich da jetzt suchen?

[MSfree]

Hab ich doch gemacht.

Code: Alles auswählen

-rw-------  1 cosinus cosinus 399M 2025-02-17 12:29 core.29727
-rw-------  1 cosinus cosinus 211M 2025-02-17 12:32 core.30161

Die Dumps sind aber sehr groß. Wonach soll ich da jetzt suchen?

Du startest damit den Debugger gdb:

Code: Alles auswählen

gdb /usr/bin/remina core.30161

Dort gibst du

Code: Alles auswählen

where

ein und bekommst damit einen Stacktrace.

[cosinus]

gdb sagt: No stack.

[MSfree]

Nochmal mit

Code: Alles auswählen

gdb /Absolutpfad/zu/remina /Absolutpfad/zum/core

und

Code: Alles auswählen

where

[cosinus]

Kannst du damit was anfangen?

Code: Alles auswählen

(gdb) where
#0  0x00007fe301dbbdcc in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fe301d67d02 in raise () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#2  0x00007fe301d504f0 in abort () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#3  0x00007fe301d5132d in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#4  0x00007fe301dc5965 in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#5  0x00007fe301dc796c in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#6  0x00007fe301dc7cb9 in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#7  0x00007fe301dca43f in free () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#8  0x00007fe2fc37fdcc in ?? () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#9  0x00007fe2fc2eabef in ?? () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#10 0x00007fe2fc2e19ab in ?? () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#11 0x00007fe2fc2e24c7 in ?? () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#12 0x00007fe2fc2e80e2 in ?? () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#13 0x00007fe2fc2c4858 in freerdp_check_fds () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#14 0x00007fe2fc2c806c in freerdp_check_event_handles () from /lib/x86_64-linux-gnu/libfreerdp3.so.3
#15 0x00007fe2ffdee692 in ?? () from /usr/lib/x86_64-linux-gnu/remmina/plugins/remmina-plugin-rdp.so
#16 0x00007fe2ffdf0936 in ?? () from /usr/lib/x86_64-linux-gnu/remmina/plugins/remmina-plugin-rdp.so
#17 0x00007fe301dba083 in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
#18 0x00007fe301e387b8 in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6

[MSfree]

Code: Alles auswählen

...
#7  0x00007fe301dca43f in free () from /usr/bin/../lib/x86_64-linux-gnu/libc.so.6
...

Das free wurde ja schon weiter oben angedeutet:

Code: Alles auswählen

[11:10:25:668] [15964:00003edb] [WARN][com.freerdp.channels.drdynvc.client] - [check_open_close_receive]: {Microsoft::Windows::RDS::DisplayControl:9} OnOpen=(nil), OnClose=0x7ffa5c2c66f0
double free or corruption (!prev)

Das ist auf jeden Fall ein Bug. free() darf nicht abstürzen, es sei denn, man übergibt einen unsinnigen Pointer oder man gibt denselben Speicherbereich zwei mal frei.

Die Frage ist nur, wie einfach sich das Problem reproduzieren läßt.

remmina unterstützt ja mehrere Protokolle (VNC, RDP, spice...). Für einen Bugreport wäre wichtig:
Passiert das nur bei einem bestimmten Protokoll?
Welches OS läuft auf der ferngewarteten Seite?
Gibt es bestimmte Maussequenzen oder Tastaursequenzen, die zum Absturz führen?
etc.

Für die Entwickler wäre es sehr hilfreich, wenn sie den Fehler einfach nachvollziehen können.

An ein Hauptspeicherproblem glaube ich hier allerdings nicht.

[cosinus]

Ich benutze das nur um Windows via RDP fernzusteuern. Die letzten Tage war ich nur auf Windows Server drauf (2016 & 2019).
Besondern häufig abgekachelt ist remmina, wenn ich mehrere Tabs offen hatte und dann einen von ihnen schließen wollte. Dabei ist dann alles von remmina abgekachelt.

[cosinus]

Zur Zeit läuft remmina einigermaßen stabil. Ich darf nur nicht auf die Idee kommen, einen Tab wegzuixen, falls ich das doch macht, stirbt remmina komplett.
Aber so kann ich zumindest per Remote auf den Servern was machen.

[wanne]

double free ist ziemlich sicher ein Bug in remmina oder seinen Abhängigkeiten... Da hilft nur updaten und bugs reporten.

[cosinus]

Nur leider schnappt der Bug nur auf meinem Büro-PC zu. Ist aber wie gesagt nicht ganz so schlimm, ich kann damit leben wenn ich einfach das Tab wegixen sein lasse.

[cosinus]

So, nun hab ich eher zufällig herausgefunden, warum das auf meinem Büro-PC immer abstürzt. Es liegt am Multi-Monitor-Betrieb!
Sobald ich den zweiten Monitor deaktiviere, kachelt remmina nicht mehr ab.

Ganz sicher bin ich mir noch nicht, aber ich teste weiter.