SIGSEGV beim Clear einer TLineSerie in TACharts (erledigt)

[h-elsner]

Ich habe mal meinen LINUX Rechner mit LINUX Mit 20.2 Uma neu installiert und darauf mit fpcupdeluxe Lazarus stable 2.0.12 + FPC 3.2.2 installiert. Mit dieser Kombination tritt nun bei allen meinen Programmen, die TAChart verwenden ein Fehler auf, wenn das Chart neu gezeichnet wird. Mit dem gleichen Quelltext und der gleichen Lazarus/FPC Version unter Windows läuft es ohne Probleme.
Scheinbar hat es irgend etwas mit dem GTK2 zu tun. Das ist zumindest meine Vermutung. Auf jeden Fall sind alle Programme betroffen und auch nur mit dem neuen LINUX Mint. Bei der vorherigen Version war es kein Problem.
Hat sonst jemand damit zu kämpfen oder betrifft das nur meine speziellen Einstellungen.

Hier mal eines der einfacheren Programme, wo der Fehler auftritt als Demo. Zum reproduzieren muss man nur eine CSV-Datei mit Import Simple CSV laden - diese wird korrekt dargestellt. Wenn man dann von 4S auf 3S umschaltet soll tas Chart neu gezeichnet werden und es knallt.

Voltage_tmp.zip

(7.29 KiB) 79-mal heruntergeladen

Gruß HE

[h-elsner]

Nachtrag:
Der Fehler tritt auf bei Chart1LineSeries1.Clear; und/oder Chart1LineSeries2.Clear;. Also nicht beim Neuzeichnen, das war blöd ausgedrückt, sondern beim neu Anzeigen. Da sollte man ja vorher die alte Linie löschen.

Gruß HE

[wp_xyz]

Ich habe dein Programm in einer VM mit Lubuntu LXQt 20.10 und Ubuntu 21.04 laufen lassen - kein Fehler, weder mit gtk2 noch mit gt5. Auch mit LMDE 4/Cinnamon sehe ich den Fehler nicht.

Das wird schwierig...

Ich denke, als erstes musst du in deinem Programm den Debugger aktivieren, in dem Upload ist er aus (wie kann man ein Programm ohne Debugger entwickeln?): Projekt-Optionen > "Compiler-Optionen" > "Debuggen" > Markieren von "Generate debugger info..." und "Zeilennummern ... anzeigen". Dann musst du in dem Projekt-Optionen unter "Hinzufügungen und Beeinflussungen" den Debug-Modus auch für alle Pakete aktivieren: "Hinzufügen" > "Benutzerdefinierte Option" > Erweiterungen" > in Zeile "Custom" klicken" und dort "-gw2" eintragen (ohne Anführungszeichen). Wenn du nun das Programm neu übersetzt, kannst du auf ChartLineSeries4.Clear einen Breakpoint setzen und, wenn das Programm dann dort anhält, F7 drücken, und du kommst in den Code von TAChart. Folge dem Code Schritt für Schritt, bis du die Stelle findest, wo der Absturz stattfindet. Vielleicht sieht man ja etwas offensichtliches. Ansonsten sehe ich schwarz...

[h-elsner]

Danke für die Hinweise. Ich hatte schon mit dem Debugger versucht. etwas zu finden, aber ohne Erfolg. "-gw2" kannte ich nicht und das ist wohl das fehlende Teil. Ich mache mich auf die Suche...

Das Beispielprogramm war das einfachste, was ich herausgekramt hatte. Ich war einfach zu faul, ein noch einfacheres Testprogramm neu zu erstellen .

Danke und Gruß HE

[h-elsner]

Tja, da steh ich nun ich armer Tor... Wie gesagt, laufe ich in den Fehler, wenn zum zweiten Mal Chart1LineSeries1.Clear; aufgerufen wird.

Die prozedure Berechnen wird aufgerufen und zuerst werden mal pauschal die LineSeries gelöscht.
Beim ersten Durchlauf mit F7 lande ich in TACustomSeries, Zeile 778 ListSource.Clear; (ja klar)
dann Zeile 1018 in function TChartSeries.ListSource: TListChartSource;.
Weiter zu Zeile 911 und 914 in function TChartSeries.GetSource: TCustomChartSource;
Zurück zu Zeile 1020 in function TChartSeries.ListSource: TListChartSource;
Weiter nochmal zu Zeile 911 und 914 in function TChartSeries.GetSource: TCustomChartSource;
Danach geht es zu Zeile 438 in TASources, procedure TListChartSource.ClearCaches; und dann immer weiter wie es sein soll. Die LineSeries, die vorher aber noch nicht aufgebaut worden ist, wird gelöscht.

Danach rufe ich Berechnen erneut auf. Gleiches Spiel:
TACustomSeries, Zeile 778 ListSource.Clear; --> Zeile 1018 --> Zeile 911 --> Zeile 914.

1__914_1result.png (353.55 KiB) 1956 mal betrachtet

Weiter wieder in Zeile 1020 --> Zeile 911 --> Zeile 914.

2__914_2result.png (314.1 KiB) 1956 mal betrachtet

Dann kommen wir in die Zeile 1021:

3__1021result.png (291.07 KiB) 1956 mal betrachtet

Und wenn ich dann F7 drücke kommt der Ausstieg:

4__1021sigsegv.png (328.15 KiB) 1956 mal betrachtet

Er zeigt dann dieses Assemblerfenster:

5__1021Assembler.png (53.36 KiB) 1956 mal betrachtet

Er sagt dann 'RunError(216)'.

Richtig interpretieren kann ich das nicht.

Gruß HE

[Winni]

Hi

216 General Protection fault
The application tried to access invalid memory space. This can be caused by several problems:

1. Dereferencing a nil pointer.
2. Trying to access memory which is out of bounds (for example, calling move with an invalid length).

aus: https://www.freepascal.org/docs-html/user/userap4.html


Winni

[h-elsner]

Ja, aber warum nur bei LINUX Mint 20.2? Bei Windows und bei älteren LINUX Mint geht es doch auch. Ich hatte vorher Mint 18.irgendwas (3 glaube ich). Dort diese Programme, die TACharts enthalten (ich kann nicht ohne auskommen , kompiliert und keine Probleme.
Das stört meine schöne LINUX Welt.

Gruß HE

[wennerer]

Hi,
ich weiß nicht ob dir das was hilft aber ich habe dein Programm unter Linux Mint 20 Cinnamon getestet.
Einmal mit Lazarus 2.0.10 r64667M FPC 3.2.0 x86_64-linux-gtk2 und dann mit Lazarus 2.1.0 r64586 FPC 3.3.1 x86_64-linux-gtk2.
Beide male habe ich dein Programm im Debugmode kompiliert, dann den Button "Import Simple CSV" geklickt. Jetzt habe ich nacheinander die beiden Dateien voltage_GUI.csv und Voltage_PX4QGC_simple.csv geladen. Mit Lazarus 2.0.10 (stable) konnte ich beide Dateien öffnen und ohne Probleme umschalten. Mit Lazarus 2.1.0 (trunk) konnte ich die Datei voltage_GUI.csv laden und problemlos umschalten. Beim Laden der Datei Voltage_PX4QGC_simple.csv kommt bei mir folgende Fehlermeldung:

debugerbericht.png (18.24 KiB) 1947 mal betrachtet

Viele Grüße
Bernd

[Winni]

Moin

Habe das Projekt runtergeladen, durch den Compiler, gestartet: Keinerlei Probleme

Linux64 Suse Tumbleweed
Lazarus 2.0.12, fpc 3.2

Hab keine Minze zur Verfügung

Winni

[Winni]

Hallo!

Nu aber kracht es, Zeile 331:

Code: Alles auswählen

if (splitlist[2]<>'') and    (splitlist[46]<>'') then begin
            v:=StrToFloat(splitlist[2]);           {Voltage}
           .....

Die Splitlist besitzt nur 2 Zeilen. Da kracht es spätestens bei der 46.
Aber natürlich schon bei der 2.

Was immer Du da treibst. Muss mich noch einlesen.

Winni

???? Oder solle ich nur den "Simple" Button nehmen.
Da gehen beide Dateien einwandfrei.

[wp_xyz]

Keine Ahnung, ob die folgenden Fehler zu dem beschriebenen Problem beitragen:

(1) Der von wennerer beschriebene Fall entsteht durch eine Division durch 0, wenn nämlich uz = S1Tab[ i ]. Da stimmt irgendwas in der Logik der Prozedur nicht. Außerdem ist unschön, dass du den Schleifen-Index außerhalb der for-Schleife verwendest. In https://www.freepascal.org/docs-html/cu ... 200013.2.4 steht: "The value of the loop variable is undefined after a loop has completed or if a loop is not executed at all. However, if the loop was terminated prematurely with an exception or a break or goto statement, the loop variable retains the value it had when the loop was exited.", denn du kannst nicht sicher sein, dass das Abbruchkriterium in der Schleife erfüllt wird, so dass die Schleife komplett durchläuft.

(2)Beim Klick auf "Import PX4CV" kommt es noch zu einem Crash, wenn Voltage_PX4QGC_simple.csv geladen wird: "List index (2) out of bounds". Das liegt daran, dass in der Zeile, in der es kracht, die List splitlist nur zwei Elemente enthält, du aber auf splitList[2] und splitlist[46] zugreifst, die es natürlich dann nicht gibt.

Je nach Compiler-Einstellungen können solche Fehler unbemerkt durchlaufen und irgendwo Schaden anrichten, der sich an ganz anderer Stelle äußert. Daher unbedingt die Bitte: Bevor du einem Fehler in TAChart nachjagst, stelle unbedingt sicher, dass dein eigenes Programm keine solchen Leichen im Keller hat. (Das soll natürlich nicht heißen, dass TAChart keine Fehler enthält).

[h-elsner]

Danke für die Antworten.
Man braucht eigentlich gar nichts laden, um den Fehler zu bekommen. Ich hätte doch mehr Sorgfalt auf die Einfachheit des Testprogramms anwenden sollen, und nicht einfach ein altes hernehmen.

Es zeigt sich aber, dass es wohl nur bei LINUX Mint 20.2 auftritt.

Das Programm war ein schnell zusammengeflicktes Testprogramm, wo ich mir verschiedene Betrachtungen über die Entladekurve eines LithiumPolymer Akkus gemacht hatte. Viele Systeme versuchen aus der Spannung eine Größe für die verbleibende Restkapazität des Akkus zu machen. Da kommen die wildesten Werte zusammen, weil die Entladekurve per Akku individuell und vom Alter abhängig ist. Input war aus vielen verschiedenen Quellen und Formaten

Um alle anderen Fehlermeldungen zu vermeiden, habe ich das Testprogramm nochmal zusammengekürzt. Zum Reproduzieren braucht man nur Neu berechnen zu klicken. Das Berechnen beim Programmstart habe ich mal auskommentiert.
Das Problem bei mir ist nun:
Beim 1. Klicken auf Neu berechnen ist alles OK, das Chart wird angezeigt.
Beim 2. Klicken auf Neu berechnen, wird beim Chart1LineSeries2.Clear; der Fehler ausgelöst.

Voltage_tmp2.zip

(3.42 KiB) 75-mal heruntergeladen

Gruß HE

[h-elsner]

Ich habe mir jetzt eine 2. Lazarus Installation angelegt: 2.2.0RC2 mit FPC 3.2.3 + Fixes. Da tritt der Fehler nicht mehr auf. Allerdings sind in dieser Installation noch keine zusätzlichen Packages installiert.

Ich werde jetzt Schritt für Schritt welche installieren und sehen, was passiert.

Gruß HE

[h-elsner]

Ich habe gerade die "stable" Version weggeworfen und arbeite mit 2.2.0RC2 mit FPC 3.2.3 + Fixes weiter.
Alle meine Programme laufen jetzt, alle nötigen Komponenten auch. Was will man mehr.

Ich glaube, man braucht nicht rückblickend suchen was da war. Auf meinem Laptop kann ich es allerdings noch nachstellen, denn da habe ich die stable Version noch laufen.

Gruß HE

[wp_xyz]

Eins würde mich noch interessieren, solange du die defekte Version noch hast: Weiter oben in den Screenshots findet man in dem Debug-Popup für FBuiltinSource den Eintrag FOwner = $7ffff5c3a3a0. In $7ffff folgen 19 Eins-Bits aufeinander - das erscheint mir für eine echte Speicheradresse sehr unwahrscheinlich. Es könnte ein Hinweis sein, dass FOwner mit einer Integer-Variablen ($7F oder $7FFFF = 32767) überschrieben worden ist. Ich meine, dass der Owner der BuiltinSource die Series selbst ist. Könntest du mal zu Beginn des Programms, z.B. im OnCreate des Formulars, einen Breakpoint setzen, und dann mit "Run" > "Evaluate/Modify" den Inhalt von "Chart1LineSeries2.FBuiltinSource" abfragen? Wenn FOwner da dieselbe Adresse hat wie die, wenn du später vor dem Absturz wieder in die Tiefen von TAChart eintauchst, dann wäre meine Befürchtung grundlos.