zmsql segfault bei Programmende

[guenterlause]

Liebes Forum!
Ich komme mit einem Problem nicht weiter und kann ein paar weitere Augen gebrauchen:

Ich möchte unter Linux mit Lazarus 1.8.2 und zmsql eine Datenbank erstellen. Mein kleines Programm im Anhang segfaultet beim Schließen, wenn Ordersfield1.size>=25.
Das Programm:

• "verbindet" sich mit dem aktuellen Verzeichnis.
• Füllt auf Knopfdruck die Datenbank mit 100 leeren Strings in das einzige Fehld Ordersfield1
• crashed beim Beenden, mutmaßlich beim freigeben des Speichers, wenn ich den Disassembler richtig deute.

Die Demoprogramme von zmsql funktionieren bei mir und ich sehe keinen relevanten Unterschied zu meinem Ansatz. Hat jemand eine Idee?

Eine weitere Frage schließt sich an: Wenn der Segfault auftritt, zeigt Lazarus mir lediglich ein Disassemblat meines Programms. Vermutlich weil der Fehler im Package auftritt und Lazrarus keinen Zugriff auf den Quelltext hat. Wie kann ich Packages im Quelltext debuggen?

Vielen Dank!

[wp_xyz]

Lazarus meckert über eine nicht vorhandene Datei "text.txt" beim Laden des Projekts, keine Ahnung, ob das wesentlich ist. Kannst du die nachliefern?

Welche Version von ZMSQL verwendest du? Es gab da vor kurzem einige Änderungen. Die Version im OPM bzw. auf CCR (https://sourceforge.net/p/lazarus-ccr/s ... nts/zmsql/) ist aktuell.

[guenterlause]

text.txt enthielt nur copy-paste-notizen. Sie ist nicht wesentlich.

Ich habe ZMSQL vor zwei Tagen mittels des OnlinePackageMangers (OPM?) installiert. Die Version ist 0.1.20.1.

[Michl]

Wie kann ich Packages im Quelltext debuggen?

Du musst das Package mit Debuginfo erstellen.

Also:
- unter Menu -> Package -> letzte Packages -> dein Package auswählen
- im nun geöffneten Packageeditor unter Einstellungen -> Compilereinstellungen -> Debuggen -> Debugging-Info-Typ den gewünschten auswählen (bei mir funktioniert Dwarf2 am besten)
- Package neu kompilieren und, wenn es ein Designpackage ist, neu installieren

[wp_xyz]

Wenn ich das Package unter Linux öffne, sind die janSQL* Dateien durchgestrichen. Im Dateisystem liegen sie in Kleinschreibung vor, aber im Projekt sind sie mit groß geschriebenem "SQL" eingetragen. Ich habe die fraglichen Dateien aus dem Package gelöscht und in korrekter Schreibweise neu eingetragen --> ich habe keinen Fehler beim Beenden des Programms (kann aber nicht sagen, ob das nun an der Änderung liegt, oder auf meinem System sonst auch funktionieren würde, weil ich deine Demo vor der Änderung nicht ausprobiert habe).

Probier's einfach mal aus. Die geänderten Package-Dateien habe ich eben auf CCR-svn hochgeladen.

Übrigens, um Packages zu debuggen, reicht es, in den Projekt-Optionen unter "Hinzufügungen und Beeinflussungen" (welch ein Name!) folgendes zu tun: "Gespeichert in der Projektsitzung" klicken > "Hinzufügen" > "Benutzerdefinierte Option" > in die neu erscheinende Zeile "Custom" die Option -gw2 eintragen > "OK". Dann werden Projekt und benötigte Packages mit Dwarf2-Debugger-Information compiliert, und man kommt mit dem Debugger auch in die Units von Packages.

[af0815]

Ich verwende generell beim Programmieren (nicht dem fertigen Code) die aktivierten Debugeinstellungen

Debugeinstellungen

Damit sieht man etliche Fehler vorher. Hast du diese EInstellungen aktiv ?

Andreas

[guenterlause]

Bevor ich mein Leid weiter klage: Danke für die bisherige Hilfe.

Wenn ich das Package unter Linux öffne, sind die janSQL* Dateien durchgestrichen. Im Dateisystem liegen sie in Kleinschreibung vor, aber im Projekt sind sie mit groß geschriebenem "SQL" eingetragen. Ich habe die fraglichen Dateien aus dem Package gelöscht und in korrekter Schreibweise neu eingetragen --> ich habe keinen Fehler beim Beenden des Programms (kann aber nicht sagen, ob das nun an der Änderung liegt, oder auf meinem System sonst auch funktionieren würde, weil ich deine Demo vor der Änderung nicht ausprobiert habe).

Das habe ich versucht, es Segfaultet bei mir noch.

Übrigens, um Packages zu debuggen, reicht es, in den Projekt-Optionen unter "Hinzufügungen und Beeinflussungen" (welch ein Name!) folgendes zu tun: "Gespeichert in der Projektsitzung" klicken > "Hinzufügen" > "Benutzerdefinierte Option" > in die neu erscheinende Zeile "Custom" die Option -gw2 eintragen > "OK". Dann werden Projekt und benötigte Packages mit Dwarf2-Debugger-Information compiliert, und man kommt mit dem Debugger auch in die Units von Packages.

Das habe ich auch versucht und das Projekt neu kompiliert. Beim Segfault lande ich immer noch im Disassembler.

Beste Grüße

Ich verwende generell beim Programmieren (nicht dem fertigen Code) die aktivierten Debugeinstellungen
Hast du diese EInstellungen aktiv ?
Andreas

Hatte ich nicht. Ich habe jetzt Release und Debug-Modi erstellen lassen und die Einstellungen wurden entsprechend gesetzt. Ich habe dann den Tipp von wp_xyz modifiziert und bei Debugging-Info-Typ "Dwarf2 (-gw2) ausgewählt und die Option -gw2 in der Zeile Custom wieder entfernt, denn die beiden Einstellungen erscheinen mir redundant. Stimmt das?

Sehr schön: Weder im Modus "Debug", noch im Modus "Release" segfaultet mein Demoprogramm.
Weniger schön: Mein eigentliches Programm segfaultet nur im Modus "Release".

Ich habe daher die Felddefinitionen der Datenbank von meinem eigentlichen Programm in das Demoprogramm übernommen. Und auch hier: Segfault bei Release, alles schön bei Debug.
Was kann das sein? Wie könnte ich vorgehen? Im Anhang ist das modifizierte Demoprogramm.

[fliegermichl]

Das ist interessant. Ich kann das Problem exakt nachvollziehen. Im Debugmodus alles gut. Release Segfault.
In Delphi gab es früher "Suchen" -> "Laufzeitfehler". Da konnte man die Fehleradresse eingeben und Delphi hat die entsprechende Stelle im Quellcode gefunden.
Das würde hier helfen.

[af0815]

Beispiel im Debugmodus und Relasemodus laufen lassen
Debug -> Ok, Heaptrace sagt auch Ok
Release -> Ok, keine Meldung

Lazarus 1.9.0 r57511 FPC 3.1.1 i386-win32-win32/win64
ZMSQL aus dem OPM

Andreas

[guenterlause]

Das ist interessant. Ich kann das Problem exakt nachvollziehen. Im Debugmodus alles gut. Release Segfault.

Welche Version und Platform benutzt du?

Lazarus 1.9.0 r57511 FPC 3.1.1 i386-win32-win32/win64
ZMSQL aus dem OPM

Könntest du sicherstellen, dass mein Demoprogramm auch bei größeren Datenbanken bei dir stabil läuft, indem du in Unit1.pas in zeile 55 den Endwert der For-Schleife erhöhst?
Ich benutze lazarus 1.8.2 mit fpc 3.0.4 unter linux 64bit. Das ist ja auf allen Ebenen unterschiedlich. Ich überlege, wie ich von hier weiter vorgehe: lazarus 1.9 aus dem SVN oder windows in der vm. Gibt es von Lazarus nightly-Builds oder muss ich das svn auschecken und selbst kompilieren?

Beste Grüße

[af0815]

Ich benutze lazarus 1.8.2 mit fpc 3.0.4 unter linux 64bit. Das ist ja auf allen Ebenen unterschiedlich. Ich überlege, wie ich von hier weiter vorgehe: lazarus 1.9 aus dem SVN oder windows in der vm. Gibt es von Lazarus nightly-Builds oder muss ich das svn auschecken und selbst kompilieren?

mittels FpcupDeluxe habe ich verschiedene Versionen auf der Platte (ohne VM).

BTW;
Lazarus 1.8.3 r57505M FPC 3.0.5 i386-win32-win32/win64
ZMSQL aus dem OPM

Debug -> Ok, Heaptrace sagt auch Ok
Release -> Ok, keine Meldung

[guenterlause]

mittels FpcupDeluxe habe ich verschiedene Versionen auf der Platte (ohne VM).

FPCupDeluxe ist ja der Wahnsinn! Das kannte ich noch nicht. Danke!

Damit sieht es aber leider nicht anders aus:
Lazarus und FPC jeweils trunk unter Linux gebaut:

• Linux Target Debug: nichts
• Linux Target Release: segfault
• Window 7 in VM mit Win64 Target Release: nichts
• Windows 10 in VM mit Win64 Target Release: segfault
• Linux Wine mit Win64 Target Release: nichts

Es scheint also weder an Version von Lazarus und FPC noch an der Platform zu liegen. Nun weiß ich nicht weiter. Noch Ideen?

[wp_xyz]

Jetzt sehe ich es auch: Win 10 64-bit (ohne VM) / Laz 1.8.2 64-bit, Exception beim Programm-Ende im Release-Mode, auch im Debug-Mode aber nur wenn HeapTrc aus ist. Ohne Debugger keine Exception. Es reicht, das Programm soweit zusammenzustreichen, dass statt die 10000 Records zu schreiben, nur Append und Post aufgerufen werden.

Vorher hatte ich in meinem Standard-32-Bit-Lazarus gearbeitet, da gibt es die Exception nicht. Ist bei dir jemand der Fehler bei 32-Bit aufgetreten?

[guenterlause]

Ich habe das Programm bei mir mal als 32bit Binary für Linux und Windows kompiliert: Weder im Release- noch im Debug-Modus kommt es damit unter Linux, Wine, Win7 oder Win10 zum Segfault. Das ist schon einmal ein gutes Teilergebnis: So könnte ich mein eigentliches Vorhaben weiter bearbeiten. Unbefriedigend jedoch, dass ich somit auf 32bit festgenagelt bin.

[wp_xyz]

Unbefriedigend jedoch, dass ich somit auf 32bit festgenagelt bin.

Was ist das Problem damit? Hast du so riesige Datenmengen?

Meines Wissens macht(e) der Debugger bei 64-Bit immer wieder Probleme, ob das noch aktuell ist, weiß ich nicht, weil ich kaum mit 64-Bit arbeite. Das würde sich mit der Beobachtung decken, dass der Fehler nicht auftritt, wenn das Programm ohne Debugger, außerhalb der IDE, läuft. Ansonsten müsste man sich auf die Fehlersuche machen...