geany Speicherzugriffsfehler
geany Speicherzugriffsfehler
Wenn ich den Editor als User im urxvt-Terminal in bullseye starte, kriege ich besagten Fehler. Ich hatte das hier (viewtopic.php?t=182227&hilit=geany+spei ... iffsfehler) schon mal gepostet, aber der dort gefundene workaraund funktioniert nicht wirklich. Die Fehlermeldung ist wieder da. Es gibt zwar zuhauf ähnliche Webseiten (meist älteren Datums), mit Lösungsvorschlägen, aber eine Entdeckung der Ursachen ist mir noch nicht untergekommen.
Re: geany Speicherzugriffsfehler
Niemand eine Idee?
Wenn ich das Geany-Konfigurationsverzeichnis unter ~/.config aus dem Weg räume (so dass es neu geschrieben wird), funktioniert Geany wieder. Fragt sich wie lange!
Wenn ich das Geany-Konfigurationsverzeichnis unter ~/.config aus dem Weg räume (so dass es neu geschrieben wird), funktioniert Geany wieder. Fragt sich wie lange!
Re: geany Speicherzugriffsfehler
Ja. Speicherzugrifsfehler sind immer das Resultat von Fehlern im Programm, die zu zufälligem Verhalten führen. Das Ding ist kaputt und wird vermutlich wieder sterben.Fragt sich wie lange!
Gibt Tools die dir beim Fehlerfinden helfen. Dazu musst du aber halt C++ können und das Ding selbst bauen, da debian keine debug-Pakete für geany bereitstellt.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: geany Speicherzugriffsfehler
Danke!, Wenn auch nicht gerade tröstlich!
C++ kann ich nicht.
Ich benutzte geany nicht oft, aber wenn, dann hatte ich bis einschließlich Buster keine Probleme.
Ich schaue gerade in den Einstellungen des Programms. Kann mir jemand laienverständlich erläutern, was man sich unter „Virtual Terminal Emulation“ vorstellen kann? Übersetzen kann ich mir das Latein schon, verstehen nicht.
C++ kann ich nicht.
Ich benutzte geany nicht oft, aber wenn, dann hatte ich bis einschließlich Buster keine Probleme.
Ich schaue gerade in den Einstellungen des Programms. Kann mir jemand laienverständlich erläutern, was man sich unter „Virtual Terminal Emulation“ vorstellen kann? Übersetzen kann ich mir das Latein schon, verstehen nicht.
Re: geany Speicherzugriffsfehler
Hi,
Was bitte ist ein urxvt-Terminal? Ich arbeite gerade mit Geany, und es zeigt nicht die Spur eines Absturzes, auch wenn es vom Terminal aus gestartet wird.fischig hat geschrieben:13.10.2021 17:35:46Wenn ich den Editor als User im urxvt-Terminal in bullseye starte ...
- king-crash
- Beiträge: 722
- Registriert: 08.08.2006 12:07:56
- Lizenz eigener Beiträge: MIT Lizenz
Re: geany Speicherzugriffsfehler
Die Codequalität von Geany ist alles andere als gut aber das Starten aus urxvt heraus funktioniert jedenfalls bei mir problemlos. Sind bei dir dort eventuell Environment Variablen falsch gesetzt?
Re: geany Speicherzugriffsfehler
Zu rxvt-unicode war ich zu faul (so wie die Entwickler wohl ebenfalls).TuxPeter hat geschrieben:Was bitte ist ein urxvt-Terminal?
Als falsch möchte ich's nicht bezeichnen, aber es mag sein, dass die so gesetzt sind, dass sie geany nicht gefallen. Geändert wurden die aber von Buster auf Bullseye nicht, jedenfalls nicht von mir. Danke für den Hinweis.king-crash hat geschrieben:Sind bei dir dort eventuell Environment Variablen falsch gesetzt?
Re: geany Speicherzugriffsfehler
Zufälliges verhalten ist nun mal zufällig...aber das Starten aus urxvt heraus funktioniert jedenfalls bei mir problemlos
rot: Moderator wanne spricht, default: User wanne spricht.
Re: geany Speicherzugriffsfehler
Vielleicht gibt es hier die Symbole:
Ich habe mich noch nicht damit bechäftigt.
Code: Alles auswählen
# dbgsym
deb http://deb.debian.org/debian-debug/ stable-debug main
deb http://deb.debian.org/debian-debug/ proposed-updates-debug main
deb http://deb.debian.org/debian-debug/ stretch-backports-debug main
deb http://deb.debian.org/debian-debug/ testing-debug main
deb http://deb.debian.org/debian-debug/ testing-proposed-updates-debug main
deb http://deb.debian.org/debian-debug/ unstable-debug main
deb http://deb.debian.org/debian-debug/ experimental-debug main
Re: geany Speicherzugriffsfehler
Irgendiwe scheint's mit dem schon genannten lokalen Konfigurationsverzeichnis zusammenzuhängen. Wenn ich's lösche (z.Z. ist es ja aufgrund des geschildeten Fehlers eh sinnlos), startet geany wieder. Ich habe jetzt mal alles, was er defaultmäßig starten will, ausgeknipst. Mal schauen, wie sich's entwickelt.
@mcb:
Das sieht ähnlich aus wie Einträge in der sources.list, aber darüber hinaus habe ich keine Ahnung, wozu der gepostete Code gut ist.
@mcb:
Das sieht ähnlich aus wie Einträge in der sources.list, aber darüber hinaus habe ich keine Ahnung, wozu der gepostete Code gut ist.
Zuletzt geändert von fischig am 15.10.2021 14:26:52, insgesamt 1-mal geändert.
Re: geany Speicherzugriffsfehler
Wie gesagt: Zufälliges Verhalten ist zufällig. Du änderst wild irgend was und dann tuts wieder so lange bis du woanders wieder was änderst... Ich glaube nicht, dass da wirklich ein direkter Zusammenhang besteht. – Was aber natürlich doch sein kann.fischig hat geschrieben:15.10.2021 14:20:42Irgendiwe scheint's mit dem schon genannten lokalen Konfigurationsverzeichnis zusammenzuhängen.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: geany Speicherzugriffsfehler
Wanne, deine Antwort ist mir zu sehr Marvin.
Bis zum dist-upgrade hatte ich keine Probleme mit geany. Andere offenbar auch jetzt nicht. Ich benutze auf der in Rede stehenden Maschine kein systemd und musste deswegen „Umleitungen fahren“. Guckst du hier: viewtopic.php?t=181683 (ist jetzt ziemlich lang!). Die von mir eingangs erwähnte ältere Info geht von Rechte-Problemen aus, konnte ich hier bisher nicht nachvollziehen.
Bis zum dist-upgrade hatte ich keine Probleme mit geany. Andere offenbar auch jetzt nicht. Ich benutze auf der in Rede stehenden Maschine kein systemd und musste deswegen „Umleitungen fahren“. Guckst du hier: viewtopic.php?t=181683 (ist jetzt ziemlich lang!). Die von mir eingangs erwähnte ältere Info geht von Rechte-Problemen aus, konnte ich hier bisher nicht nachvollziehen.
Re: geany Speicherzugriffsfehler
So pauschal als „zufällig“ abtun würde ich einen Segfault nicht. Möglich ist es natürlich, aber manch einer lässt sich ja zuverlässig reproduzieren.
(Zu schauen) dass ein Fehler anscheinend bei unveränderter Standardkonfiguration nicht auftaucht, ist doch ein denkbarer, erster Schritt in einer Bugsuche. Und erklärt immerhin, warum der Fehler (noch) existiert und womöglich noch nirgendwo gemeldet wurde. Jetzt könnte fischig in einzelnen Schritten seine Konfiguration wiederherstellen und schauen, welche Veränderung den Fehler produziert – als Alternative dazu, direkt „richtig“ zu Debuggen, was natürlich vermutlich schneller zum Ziel führt, aber andere Kenntnisse braucht.wanne hat geschrieben:15.10.2021 14:26:33Du änderst wild irgend was und dann tuts wieder so lange bis du woanders wieder was änderst... Ich glaube nicht, dass da wirklich ein direkter Zusammenhang besteht. – Was aber natürlich doch sein kann.
Manchmal bekannt als Just (another) Terminal Hacker.
Re: geany Speicherzugriffsfehler
Dort gibt es Debugsymbole (sofern vorhanden)...fischig hat geschrieben:15.10.2021 14:20:42..............
@mcb:
Das sieht ähnlich aus wie Einträge in der sources.list, aber darüber hinaus habe ich keine Ahnung, wozu der gepostete Code gut ist.
Alternativ Geany selber bauen dann hat man auch ein Paket mit Debugsymbolen. Ich kann aber wie gesagt nicht fundiert helfen.
Re: geany Speicherzugriffsfehler
Ich kann den Feler nicht mehr reproduzieren.
In den Einstellungen habe ich „Dateien aus der letzten Sitzung laden“ wieder reaktiviert
„Virtual Terminal Emulation (VTE) laden“ und „Plugins laden“ bleiben deaktiviert.
Ich weiß nicht, was VTE sein soll. Und geany-plugins habe ich gar nicht installiert.
Aber auch wenn ich diese beiden letztgenannten Einstellungen wieder aktiviere, tritt momentan der Fehler nicht mehr auf.
So ganz falsch scheint wanne mit Voodoo-Code nicht zu liegen! Aber was weiß ich schon.
In den Einstellungen habe ich „Dateien aus der letzten Sitzung laden“ wieder reaktiviert
„Virtual Terminal Emulation (VTE) laden“ und „Plugins laden“ bleiben deaktiviert.
Ich weiß nicht, was VTE sein soll. Und geany-plugins habe ich gar nicht installiert.
Aber auch wenn ich diese beiden letztgenannten Einstellungen wieder aktiviere, tritt momentan der Fehler nicht mehr auf.
So ganz falsch scheint wanne mit Voodoo-Code nicht zu liegen! Aber was weiß ich schon.
Re: geany Speicherzugriffsfehler
Nein. Es gibt genau einen Zuverlässigen Segfault: Der auf NULL und der wird mit: de-referencing a NULL pointer und nicht mit Segfault ausgegeben. Segfault ist ja auf ne Stelle im Speicher zuzugreifen, die nicht für dich reserviert ist. Da aber preventiv und eventuell an zufälligen Stellen reserviert wird, kannst du immer aus Zufall eigenen Speicher treffen. Nur 0 wird bei UNIX-Artigen absichtlich nie vergeben. (Eben genau, damit man dafür sogen kann, dass sich das Programm zuverlässig auf die Fresse legt.) Man kann nur die Wahrscheinlichkeit hoch drehen: Beispielsweise indem man es häufig hintereinander an ausreichend absurden Stellen versucht. Aber am Ende kann das selbe Programm mit einer andere glibc/Kernel immer wieder Funktionieren.JTH hat geschrieben:15.10.2021 14:42:19So pauschal als „zufällig“ abtun würde ich einen Segfault nicht. Möglich ist es natürlich, aber manch einer lässt sich ja zuverlässig reproduzieren.
Wie gesagt: Segfaults sind niemals zuverlässig. Nur weil irgend ein Programm ein mal durchläuft, heißt es nicht, dass es das auf einem anderen Rechner oder mit minimal anderer glibc-Version etwas mehr laufenden anderen Programmen etc. auch tut. Und so wird das halt hässlich. Wenn du einen Teil ausschließen willst, musst du auf möglichst vielen möglichst unterschiedlichen Systemen testen und kannst dir doch nie sicher sein, dass es nicht nur Zufall war.wanne hat geschrieben:15.10.2021 14:26:33(Zu schauen) dass ein Fehler anscheinend bei unveränderter Standardkonfiguration nicht auftaucht, ist doch ein denkbarer, erster Schritt in einer Bugsuche. Und erklärt immerhin, warum der Fehler (noch) existiert und womöglich noch nirgendwo gemeldet wurde. Jetzt könnte fischig in einzelnen Schritten seine Konfiguration wiederherstellen und schauen, welche Veränderung den Fehler produziert – als Alternative dazu, direkt „richtig“ zu Debuggen, was natürlich vermutlich schneller zum Ziel führt, aber andere Kenntnisse braucht.
rot: Moderator wanne spricht, default: User wanne spricht.