Moneyplex - Meldungen im Log von Debian vor Absturz · homebanking-hilfe.de / onlinebanking-forum.de

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 04.03.2023 - 17:03 Uhr · #1

Hallo zusammen,

beim Abrufen der Konten ist mir heute moneyplex abgestürzt. Es ließ sich wieder starten und ich konnte weiter arbeiten.

Da es in letzter Zeit ein paar Mal passiert ist, hab ich heute ins log geschaut und etliche Meldungen gefunden, die nicht nur zu dem Absturz passen, sondern auch bei "nicht abstürzendem" mp geschrieben werden.

Mein MP läuft auf einer echte Maschine (eigenes Blech, ein Intel Deskmini mit integrierter Grafik Mesa Intel® HD Graphics 510 (SKL GT1), alle Treiber von Debian) unter einem aktuellen Debian Bullseye mit Gnome 3.38.5 unter X11. Eigene Maschine für banking, also keine Frickeleien usw. MP ist 20.0 Pro Build L-24799 64bit

Hat das noch jemand und hat einen Tip für mich?

Beste Grüße
Stefan

Die Meldungen:

direkt vor dem Absturz unter "Sicherheit":
"WARNING: TGtk2WidgetSet.InvalidateRect refused invalida" -> wenn ich das aufklappe:
../../../glib/gmem.c:341: overflow allocating 18446744073709551615*18446744073709551615 bytes
dann einige EInträge mit "assertion 'GDK_IS_PIXBUF (pixbuf)' failed" die sich auf
get_n_channels, get_rowstride, get_pixels_with_length und get_height bzw length beziehen

Zudem gibt das System direkt nach Start von mp nach dem loggen vom prestart mit "... ExecuteProcess result code = -1 Version 2018-12-02" die folgenden Meldungen direkt nacheinander aus:

gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe000a3

moneyplex: TGtk2MemoStrings.QueueSelectLength 25 (insgesamt 4 Meldungen mit length 25,92 117 124)

moneyplex: WARNING: obsolete call to RecreateWnd for TEmbedFondsContainer

moneyplex: Warning: TWinControl.DestroyHandle :TEmbedFondsContainer Handle not Allocated

moneyplex: WARNING: obsolete call to RecreateWnd for TEmbedContainer

moneyplex: Warning: TWinControl.DestroyHandle :TEmbedContainer Handle not Allocated

moneyplex: Warning: TWinControl.DestroyHandle :TEmbedContainer Handle not Allocated

moneyplex: Warning: TWinControl.DestroyHandle :TEmbedContainer Handle not Allocated

moneyplex: TGtk2MemoStrings.QueueSelectLength 229

moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB (4mal diese Meldung)

Dann rumpelts ..

infoman

Benutzer

Geschlecht:
Beiträge: 7097
Dabei seit: 06 / 2008

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 04.03.2023 - 18:41 Uhr · #2

Zitat geschrieben von Stefan193

unter einem aktuellen Debian Bullseye mit Gnome 3.38.5

dass wäre dann das hier https://www.debian.org/releases/bullseye/ ? (Debian 11.6 wurde am 17. Dezember 2022 veröffentlicht. )

emmi

Benutzer

Geschlecht: keine Angabe
Beiträge: 176
Dabei seit: 11 / 2012

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 04.03.2023 - 23:23 Uhr · #3

Zitat geschrieben von Stefan193

moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB (4mal diese Meldung)

Ist vermutlich harmlos. Sieht man immer bei ./prestart im moneyplex Verzeichnis. Hier aber 5mal. Dann kommt irgendwas wie

Code

(moneyplex:5269): Gtk-CRITICAL **: 22:40:10.963: gtk_window_realize_icon: assertion 'info->icon_pixmap == NULL' failed
TGtk2MemoStrings.QueueSelectLength 405
(TGtk2MemoStrings) UpdateMemoSelLengthCB
GTKKillFocusCBAfter: abc: :TEbEdit
GTKKillFocusCBAfter: abc: ENameEdit:TBasicEdit
...

Ist schon lange so und dann kann man moneyplex doch "problemlos" benutzen. Wobei immer wieder Gtk-CRITICAL und GLib-CRITICAL erscheinen.

Rumpeln ist vermutlich eine gute Beschreibung, nur sagt es leider nicht, ob und was denn noch ausgegeben wird.

"strace -f" könnte helfen, erzeugt jede Menge Ausgaben, aber die letzten könnten auf das Problem hinweisen. Ein stack trace wäre hilfreich, aber so etwas habe ich bei moneyplex noch nicht gesehen.

Ansonsten kann man nur das Übliche fragen. Hat's schon mal problemlos funktioniert, wurden seit dem "Updates" gemacht?

Manfred M

Benutzer

Geschlecht:
Herkunft: NRW
Beiträge: 72
Dabei seit: 12 / 2015

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.03.2023 - 11:28 Uhr · #4

Hallo zusammen,

auch unter Ubuntu (22.04 LTS) gab es bei mir in den letzten Monaten mal immer wieder Abstürze beim Abrufen von Konten und beim Ausführen von Überweisungen bei moneyplex. Nach einem Neustart von moneyplex funktionierte es dann wieder. Nach Abstürzen bei Überweisungen logge ich mich dann vorsichtshalber immer noch einmal online ein, um den Kontostatus zu überprüfen. Das ist schon etwas nervig und ich hoffe, dass das Problem bald behoben werden kann.

moneyplex ist bei mir ebenfalls 20.0 Pro Build L-24799 64bit.

Viele Grüße
Manfred

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.03.2023 - 12:28 Uhr · #5

Hallo zusammen,

danke für die rege Beteiligung

@infoman: Ja, genau dieses. Auch auf aktuellem Stand, alle Updates usw.

@emmi: Ja, solche Meldungen hab ich auch noch im log, wobei ich die nicht eindeutig mp zuordnen konnte bislang. MP funktioniert, aber dass es beim Abrufen abstürzt (egal ob Überweisungen beteiligt sind oder nicht), also bei der Interaktion mit den Banken, ist bislang nur ganz vereinzelt vorgekommen, meist kam es dazu, wenn bei der Interaktion irgendwas "hängt" auf Bankseite oder bei den Kursen (comdirect und matrica werden als Kursquelle benutzt). Da breche ich auf keinen Fall über das Dialogfenster in MP ab, sondern warte geduldig bis sich was tut.

@manfred: Liest sich wie mein Problem auch. Nachdem Ubuntu auf Debian beruht, ist es wahrscheinlich, dass das Problem von "upstream" irgendwo herkommt oder an MP liegt, dessen Codebasis ist m.E. nicht die Jüngste.

@alle: Hintergrund der Frage ist mein Unbehagen, ob sich da was zusammenbraut, was man rechtzeitig adressieren sollte, bevor es uns um die Ohren fliegt. Ich bin MP-User seit OS/2 Zeiten und würde gerne dabei bleiben. Dass die Oberfläche von MP in Sachen Zusammenarbeit mit dem System etwas "unrund" ist, ist seit langem so. Ich komm aber damit klar.

Um auszuschließen, dass es ausgerechnet was an meinem System ist, hab ich hier gefragt. Weitere Infos oder Anregungen sind willkommen.

Beste Grüße
Stefan

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Nachtrag: Meldungen aus dem Log

· Gepostet: 05.03.2023 - 14:44 Uhr · #6

Folgendes wird im log protokolliert, wenn man MP startet und nichts weiter macht, nicht mal sich anmeldet. Also nur prestart.

Code

14:35:36 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe0039e
14:35:36 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe0039e
14:35:36 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe0039e
14:35:36 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe0039e
14:35:36 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe0039e
14:35:35 moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB
14:35:35 moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB
14:35:35 moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB
14:35:35 moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB
14:35:35 moneyplex: (TGtk2MemoStrings) UpdateMemoSelLengthCB
14:35:35 moneyplex: TGtk2MemoStrings.QueueSelectLength 229
14:35:35 moneyplex: Warning: TWinControl.DestroyHandle :TEmbedContainer Handle not Allocated
14:35:35 moneyplex: WARNING: obsolete call to RecreateWnd for TEmbedContainer
14:35:35 moneyplex: Warning: TWinControl.DestroyHandle :TEmbedContainer Handle not Allocated
14:35:35 moneyplex: WARNING: obsolete call to RecreateWnd for TEmbedContainer
14:35:35 moneyplex: Warning: TWinControl.DestroyHandle :TEmbedFondsContainer Handle not Allocated
14:35:35 moneyplex: WARNING: obsolete call to RecreateWnd for TEmbedFondsContainer
14:35:35 moneyplex: TGtk2MemoStrings.QueueSelectLength 124
14:35:35 moneyplex: TGtk2MemoStrings.QueueSelectLength 117
14:35:35 moneyplex: TGtk2MemoStrings.QueueSelectLength 92
14:35:35 moneyplex: TGtk2MemoStrings.QueueSelectLength 25
14:35:35 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe000a3
14:35:35 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe000a3
14:35:35 gnome-shell: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe000a3
14:35:34 prestart: ... ExecuteProcess result code = -1 Version 2018-12-02
14:35:34 prestart: ... ExecuteProcess result code = -1 Version 2018-12-02
14:35:34 prestart: Starting ... /home/stefan/moneyplex/moneyplex
14:35:34 systemd: Started Application launched by gnome-shell.

emmi

Benutzer

Geschlecht: keine Angabe
Beiträge: 176
Dabei seit: 11 / 2012

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.03.2023 - 16:11 Uhr · #7

Wie gesagt, die Meldungen sind bekannt, nicht nur mir.

Wenn man prestart im Terminal aufruft, werden all diese Meldungen dort protokolliert. Dann sollte man dort doch auch die letzten Meldungen sehen, bevor moneyplex abstürzt. Aus meiner Sicht sind nur diese letzten Meldungen interessant. Darin könnte ein Hinweis auf das Problem auftauchen. Aber nix genaues/besseres weiß ich auch nicht. Alle anderen Meldungen kann man ignorieren, tun andere auch.

Wie gesagt, ich würde einen Versuch mit strace machen. Wie war das denn nun, lief moneyplex in dieser Umgebung irgendwann mal problemlos? Offensichtlich unter Ubuntu 22.04 LTS. Aber da gab es/gibt es auch Updates. Aktuelle Version ist 22.04.2 LTS, freigegeben am 23. Februar. Vermutlich sind danach Updates verfügbar gewesen und ggf. automatisch eingespielt worden.

Auf Mint 21, Ubuntu 22.04 basierend aber sehr wahrscheinlich nicht 22.04.2, sehe ich solche Problem nicht, was aber wenig aussagt oder wenig hilfreich erscheint.

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 06.03.2023 - 17:57 Uhr · #8

@emmi: Danke. Das was ich gepostet hab waren im Prinzip die Meldungen, die auch vor einem Absturz kommen.

Ob es mal unter vorigen Versionen anders lief, ist m.E. eine Frage die nur zur Fehlersuche dient. "Stable" bekommt ja nur die Sicherheitsupdates, die kann man ja nicht weglassen.

Ich könnte auch nicht explizit sagen, welches der Updates es nun war. So detailliert hab ich das nicht verfolgt.

Mit dem strace muss ich mal schauen ob ich das hinbekomme.

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 06.03.2023 - 19:45 Uhr · #9

Aalso:

strace einmal durchgeführt, während MP einmal startet, die Konten abruft und wieder beendet wird. Ohne Absturz.

. Ich weiß nicht, ob ich den trace hier komplett posten kann wegen der Daten drin, daher mal das was mir auffiel:

Zuerst das hier, aber da kommt er noch drüber:

Code

access("/etc/ld.so.preload", R_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

Dann werden etwa 500 lines protokolliert, in denen er libs öffnet, Memory zuweist usw. Danach wird geprüft ob Pfade zu selinux existieren:

Code

statfs("/sys/fs/selinux", 0x7ffc4c3f3320) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
statfs("/selinux", 0x7ffc4c3f3320)      = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
brk(NULL)                               = 0x1c2c000
brk(0x1c4d000)                          = 0x1c4d000
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "nodev\tsysfs\nnodev\ttmpfs\nnodev\tbd"..., 1024) = 336
read(3, "", 1024)                       = 0
close(3)                                = 0
access("/etc/selinux/config", F_OK)     = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)

Dann wird die timezone geprüft. Und dann sucht er nach einer Datei bzw Verzeichnissen und eine findet er nicht: libgdk-x11-2.0.so:

Code

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=122880, ...}) = 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/tls/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/tls", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=122880, ...}) = 0
openat(AT_FDCWD, "/lib/tls/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/tls/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/tls/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/tls", 0x7ffc4c3f29d0)        = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/x86_64", 0x7ffc4c3f29d0)     = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib/x86_64", 0x7ffc4c3f29d0)     = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/lib/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
openat(AT_FDCWD, "/usr/lib/tls/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/tls/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/tls/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/tls/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/tls/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/tls", 0x7ffc4c3f29d0)    = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/x86_64/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib/x86_64", 0x7ffc4c3f29d0) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/lib/libgdk-x11-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Ob das was ausmacht? Keine Ahnung, aber ich vermute schon, Das ist eine realtiv zentrale Bibliothek und die vielen Meldungen zu Fensterfehlern könnten damit was zu tun haben.

Bei mir heißt die Datei "libgdk-x11-2.0.so.0" und weist als Verknüpfung auf "libgdk-x11-2.0.so.0.2400.33" die direkt unter "/usr/lib/x86_64-linux-gnu" steht. Da sucht er aber nicht direkt, sondern in dem dortigen Unterverzeichnis "tls" das es bei mir aber nicht gibt.

Immerhin hab ich einen Zusammenhang gefunden:

Die 5 Meldungen "Glib-Critical .....g_source_remove: assertion 'tag > 0' failed" kommen m.E. daher, dass MP auf der Suche nach der Datei "gdk-pixbuf.mo" diverse Orte durchsucht und 5x scheitert, beim 6. Mal findet er sie. Offenbar wird das protokolliert und ich konnte das auch zusammenbringen

Code

openat(AT_FDCWD, "/usr/share/locale/de_DE.UTF-8/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE.utf8/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de_DE/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.UTF-8/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de.utf8/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/usr/share/locale/de/LC_MESSAGES/gdk-pixbuf.mo", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=23921, ...}) = 0

OK, mit den Erkenntnissen ist mal Schluss für eben. Ich muss mal einen Tee machen und nachdenken.

Beste Grüße
Stefan

emmi

Benutzer

Geschlecht: keine Angabe
Beiträge: 176
Dabei seit: 11 / 2012

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 07.03.2023 - 00:43 Uhr · #10

moneyplex selbst benötigt die .0 und findet sie auch.

Aus meinem strace:
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3
Das ist relativ früh im Log, weil moneyplex dagegen gelinkt ist.

Die Shared library ohne ".0" wird später gesucht und auch auf meinem System nicht gefunden. moneyplex versucht sie mit dlopen zu laden. Warum, ist nicht ersichtlich. Jedenfalls findet man den string "libgdk-x11-2.0.so" in moneyplex (und mit Geduld und ltrace auch den Aufruf).

Es sieht für mich aber nicht so aus, als hätte das etwas mit den CRITICALs zu tun, die kommen von Gtk und Glib.

Ebenso sehe ich noch keinen Zusammenhang dieser fehlenden Bibliothek mit dem Absturz, den es - wenn ich es richtig verstanden habe - bei dem gezeigten Log nicht gab.

Wie gesagt, ich vermute (oder hoffe) nur, dass strace kurz vor dem Absturz einen Hinweis ausgibt.

hibiscus

Benutzer

Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10611
Dabei seit: 03 / 2005

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 07.03.2023 - 08:08 Uhr · #11

Diese Meldungen von nicht gefundenden Libs mit strace sind völlig normal. Das würde bei Firefox oder jeder anderen GTK-basierten Anwendung genauso aussehen. Relevant wäre nur die Ausgaben unmittelbar vor dem Crash. Wie sieht denn der Crash in strace aus? Sieht man einen SegFault?

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 07.03.2023 - 12:43 Uhr · #12

Zitat geschrieben von emmi

Stimmt. Ist bei mir auch so. Leider hab ich nicht nach "libgdk-x11-2.0.so.0" gesucht, sondern nur die EOENT. Anfängerfehler..

Zitat geschrieben von emmi

Die Shared library ohne ".0" wird später gesucht und auch auf meinem System nicht gefunden. moneyplex versucht sie mit dlopen zu laden. Warum, ist nicht ersichtlich. Jedenfalls findet man den string "libgdk-x11-2.0.so" in moneyplex (und mit Geduld und ltrace auch den Aufruf).

OK, ltrace -- ich muss mal nachschauen wie das nun fuktioniert.

Nun - ich hab da auf Linux nicht die Erfahrung. Hab einstenmals auf "ganz großem Eisen" gearbeitet, mit (IBM-Macro)Assembler, Cobol, Rexx, QMF, TSO mit SDSF und allem möglichen. Bestände mit um 10 Mio Kunden schrecken mich nicht samt dazu gehörenden Finanzkonten im gut zweistelligen Mio-Bereich und schier "endloser" Umsatzanzahl (> 100 Mio online) samt Begleitbeständen aller Art. PL/1 sagt mir was und Roscoe auch noch. Da war dann OS/2 fast zwangsläufig auf dem PC daheim. Irgendwann "musste" ich zu Windows, obwohl ich durch Win95 vorgewarnt war. Nach dem ersten Schock mit WinNT und Win2000 hielt ich mein OS/2 so lange am Leben wie es ging. Da gabs dann durch die div. Portierungen erste Kontakte mit Linux (cdrecord bspw). Bis Ende des Supports zu Win7 lief es hier in der Familie zweigleisig, aber seitdem ist zu 98% auf Linux umgestellt. Aber so tief bin ich nicht drin bisher, man sehe es mir nach

Zitat geschrieben von emmi

Es sieht für mich aber nicht so aus, als hätte das etwas mit den CRITICALs zu tun, die kommen von Gtk und Glib.

Nein, seh ich auch nicht, die kommen m.E. aus dem Bereich gdk-pixbuf.mo.

Zitat geschrieben von emmi

Ebenso sehe ich noch keinen Zusammenhang dieser fehlenden Bibliothek mit dem Absturz, den es - wenn ich es richtig verstanden habe - bei dem gezeigten Log nicht gab.

Korrekt. So seh ich das auch. Hat mich nur erstaunt, dass hier so viele Speicherorte "abgeklappert" werde, das bin ich nicht gewohnt (siehe oben, ich bin Sourcen/Code gewöhnt, die mit 4k "groß" sind). Aber hier spielt die Musik wohl anders ... und ich hab so gut wie Null Ahnung von den Spezifika.

Ich konnte mit laufendem strace bisher keinen Absturz provozieren, ist ja logisch ...

das Ding reiß sich zusammen wenn man auf die Finger schaut ..

Zitat geschrieben von emmi

Wie gesagt, ich vermute (oder hoffe) nur, dass strace kurz vor dem Absturz einen Hinweis ausgibt.

Ich versuche es heute im Lauf des Tages nochmal ob sich die Kiste dazu herablässt, unter Beobachtung abzustürzen.

Danke schon mal für den Input.

emmi

Benutzer

Geschlecht: keine Angabe
Beiträge: 176
Dabei seit: 11 / 2012

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 08.03.2023 - 00:18 Uhr · #13

Zitat geschrieben von Stefan193

OK, ltrace -- ich muss mal nachschauen wie das nun fuktioniert.

Protokolliert so ziemlich alles. Deshalb auch "Geduld". Selbst bis der erste Bildschirm kommt, dauert es. Das hat mir gereicht, um die "libgdk-x11-2.0.so" zu finden. Man kann auch filtern, wenn man weiß, wonach man sucht. Ob und wie man sich an einen laufenden Prozess anhängen kann, mit -p pid, weiß ich nicht, habe ich nicht probiert.

Zitat geschrieben von Stefan193

Nun - ich hab da auf Linux nicht die Erfahrung. Hab einstenmals auf "ganz großem Eisen" gearbeitet, mit (IBM-Macro)Assembler, Cobol, Rexx, QMF, TSO mit SDSF und allem möglichen.

Habe, und mische da auch noch mit, auf mittelgroßem Eisen gearbeitet. Dort gibt's im Fehlerfall einen TRACEBACK. Zeigt Programm, Modul, Routine und Zeilennummer an, an dem der Absturz passiert und natürlich die Aufrufhierarchie. Kommt automatisch mit, muss man explizit unterdrücken, wenn man diese Einblicke in den eigenen Code nicht den Kunden zeigen will. Soll's ja geben.

Zitat geschrieben von Stefan193

Hat mich nur erstaunt, dass hier so viele Speicherorte "abgeklappert" werde, das bin ich nicht gewohnt (siehe oben, ich bin Sourcen/Code gewöhnt, die mit 4k "groß" sind). Aber hier spielt die Musik wohl anders ... und ich hab so gut wie Null Ahnung von den Spezifika.

Hat aus meiner Sicht erstmal nichts mit der Code-Größe zu tun. Aber heute benötigt man jede Menge Bibliotheken, Shared libraries. Und da wird dann alles abgeklappert, wo sie denn sein könnten.. Die Pfade sind vorkonfiguriert. Man kann aber auch ein Programm so starten, dass nur die Pfade abgesucht werden, von denen man weiss, dass da die nötigen Shared libraries drin sind. Macht kaum jemand, ist ja sowieso schon alles im Speicher.

Manfred M

Benutzer

Geschlecht:
Herkunft: NRW
Beiträge: 72
Dabei seit: 12 / 2015

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 12.03.2023 - 10:05 Uhr · #14

Hallo zusammen,

heute habe ich tatsächlich eine Abweichung in der Konsistenz festgestellt: Nach einem Absturz bei einer Überweisung behielt moneyplex den Überweisungsauftrag in der Liste der offenen Überweisungen, obwohl der Auftrag bereits ausgeführt wurde. Beim Ausführen der Überweisungen hätte moneyplex den Auftrag noch einmal ausgeführt.

Ich kann daher nur noch einmal empfehlen, nach einem Absturz von moneyplex, die erfolgten Buchungen in den Onlineportalen der Banken zu überprüfen.

Da ich die offene Überweisung nicht manuell ins Archiv verschieben kann, werde ich sie wohl löschen und auf die Archivierung verzichten müssen.

Viele Grüße
Manfred

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 16.03.2023 - 16:41 Uhr · #15

Hallo zusammen,
eine Rückmeldung zwischendurch.

Voodooo

Seit ich moneyplex mit strace benutze, ist es nicht mehr abgestürzt. ich kann also derzeit nicht mit aktuelleren Infos dienen.

Nur als Zwischeninfo.

Beste Grüße
Stefan

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 04.06.2023 - 21:49 Uhr · #16

Hallo zusammen,

heute konnte ich einen Absturz loggen (strace -o), der dem entsprach, den ich zu Anfang beschrieben hatte. Nach dem Abruf der Umsätze brauchte die Kursaktualisierung etwa 5 Minuten. Währenddessen ist das kleine Fenster mit den stattfindenden Aktionen (Umsatzabrufe, Kursabruf etc) offen aber der untere -bei mir gelbe- Fortschrittsbalken für die Kursaktualisierung blieb stehen. Im Monexplex Hauptfenster waren die Schaltflächen "Ausführen" und "Abrufen" währenddessen ausgegraut. Unten rechts die "Fortschrittsanzeige" hing ebenfalls.

Der hinterste Teil des strace EDIT: Der Teil, der nur im Terminal sichtbar ist!- sieht so aus wie unten dargestellt. Im trace selbst finde ich das nicht:

Code

SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
GTKKillFocusCBAfter: abc: KategoCombo:TMatchCombo
GTKKillFocusCBAfter: abc: :TEbEdit
GTKKillFocusCBAfter: abc: :TEbEdit
GTKKillFocusCBAfter: abc: :TEbEdit
GTKKillFocusCBAfter: abc: :TEbEdit
TGtk2MemoStrings.QueueSelectLength 9446
(TGtk2MemoStrings) UpdateMemoSelLengthCB

(moneyplex:3062): GLib-CRITICAL **: 21:03:39.446: g_source_remove: assertion 'tag > 0' failed
TGtk2MemoStrings.QueueSelectLength 10614
(TGtk2MemoStrings) UpdateMemoSelLengthCB

(moneyplex:3062): GLib-CRITICAL **: 21:04:45.711: g_source_remove: assertion 'tag > 0' failed
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
SSS Gtk2ScrolledWindowScrollCB
TApplication.HandleException Access violation
  Stack trace:
  $00007F81B1F393AE
[FORMS.PP] ExceptionOccurred
  Sender=EAccessViolation
  Exception=Access violation
  Stack trace:
  $00007F81B23B887C
TApplication.HandleException: there was another exception during showing the first exception
  Stack trace:
  $00007F81B23B887C
stefan@Deskmini:~/moneyplex$

Was fang ich mit der Meldung im Detail an? Es gab also irgendein Zugriffsproblem - nur wo?

Devisen hole ich von der Standardquelle, Kurse hole ich von www.comdirect.de und wo ich das jetzt schreibe, bemerke ich dass ich für ein einzelnes Wertpapier noch die Standardkursquelle benutze. Allerdings ist das WP noch relativ neu, aber ich kann nicht mit Bestimmtheit sagen, ob die Abstürze davor auch schon da waren). Ich habs jetzt mal umgestellt wie die anderen und beobachte weiter.

Anregungen sind aber jederzeit willkommen.

Beste Grüße
Stefan

emmi

Benutzer

Geschlecht: keine Angabe
Beiträge: 176
Dabei seit: 11 / 2012

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.06.2023 - 15:18 Uhr · #17

Nichts Genaues sieht man nicht, leider. Da Details hier vermutlich niemanden interessieren, ist es auch egal, wenn ich hier antworte und mal wieder (m)ein Beitrag spurlos verschwindet.

Die Access Violation tritt also an der Adresse 00007F81B1F393AE auf.

Da ist vermutliche eine Shared Library (denn moneyplex wird an die vom Linker zugewiesenen Adresssen geladen, die man man mit readelf oder objdump sehen kann). Welche Shared Library dort ist, steht in der strace-Ausgabe - ist aber nicht so einfach zu finden. Leider sagt das nichts darüber aus, wie es zu der Access Violation gekommen ist. Denn der komplette Stack Trace kann nicht ausgegeben werden, da bei der Ausgabe wieder eine Access Violation auftritt. Sonst würde im Stack Trace eine Code-Adresse von moneyplex auftauchen. Schade. Dass da wiederum eine Access Violation auftritt, kann daran liegen, dass der Stack überschrieben wurde. Das kann auch der Auslöser für die erste Access Violation gewesen sein, also das Grundübel. Die Shared Library, in der die erste Access Violation auftritt, kann nur ein vager Hinweis darauf sein, wie das passiert ist. Die Shared Library selbst kann unschuldig sein.

In der strace-Ausgabe findet man die Mapping-Informationen, also welche Shared library wo im Speicher ist. Das sieht in einem Beispiel so aus:

Code

openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\237\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0 \0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0"..., 48, 848) = 48
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0i8\235HZ\227\223\333\350s\360\352,\223\340."..., 68, 896) = 68
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2216304, ...}, AT_EMPTY_PATH) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2260560, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f689c57f000
mmap(0x7f689c5a7000, 1658880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0x7f689c5a7000
mmap(0x7f689c73c000, 360448, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bd000) = 0x7f689c73c000
mmap(0x7f689c794000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x214000) = 0x7f689c794000
mmap(0x7f689c79a000, 52816, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f689c79a000
close(3) = 0

Daraus erkennt man, dass der Code der libc auf Adresse 0x7f689c5a7000 beginnt und 1658880 (dezimal) Byte groß ist. Für jede Shared Library sind die Mapping-Informationen in der strace-Ausgabe. Somit kann man zur Adresse der Access Violation die Shared Library bestimmen. (Wie man weiss, werden Shared Libraries bei jedem Programmlauf absichtlich an anderen Stellen "gemappt".)

Ob bei der Fehlersuche ein Core Dump hilft, ist fraglich. Wie man den auf Debian Bullseye aktiviert, weiß ich jetzt nicht auswendig. Wenn er aktiviert ist, kann man sich mit gdb ./moneyplex ./core.<PID> den Dump anschauen. Fraglich, weil ein "backtrace" dann die gleichen Probleme mit dem Stack hat. Ansonsten sollte man die Sourcen und Symbole zur Verfügung haben, um den Fehler eingrenzen zu können.

Ob die Firma Matrica den Core Dump haben will und damit etwas anfangen kann, ist eine andere Frage.

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.06.2023 - 22:35 Uhr · #18

Hi Emmi,

mir ist es nicht egal und ich schätze Deinen Beitrag sehr. Ich muss ihn mal verdauen und dann schau ich mal wie weit ich mit dem gespeicherten strace-Ergebnissen kommen...

Bis nachher

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.06.2023 - 23:10 Uhr · #19

Ok, der Beitrag ging daneben, hab ihn gelöscht, hier Versuch Nr.2

Keine der Adresse, die ich nach dem von Dir genannten Muster aus der Terminalausgabe bei der access violation lesen kann, taucht im strace auf.

Der strace ist leider zu lang um ihn hier in einem Codeblock einzufügen... ich konnte den Beitrag auch nicht editieren.

Stefan193

Benutzer

Geschlecht: keine Angabe
Beiträge: 70
Dabei seit: 09 / 2017

Betreff:

Re: Moneyplex - Meldungen im Log von Debian vor Absturz

· Gepostet: 05.06.2023 - 23:19 Uhr · #20

Ok, vier mal versucht, es geht nicht. Der Inhalt ist zu lang für die Codebox, sie fasst nur 451 Zeilen aus dem trace.

Ich geb auf. Hier kann ich nix weiter ausrichten, auch wenn ich mich an den Service wenden sollte. Die Chance dass matrice da was macht, seh ich als gering an. Wenn es in der neuen Version auch wieder auftauchen sollte, dann hat das auch einen Sinn..

Danke an alle die was beigetragen haben. Emmi, von Dir hab ich was gelernt.