Heap dump

[Aliobaba]

Hallo,

ich habe ein Projekt zunächst auf der Windowsoberfläche programmiert, da ich aber nur noch selten mit Windows arbeite, programmierte ich meine Anwendung auf der Linux (Kubuntu) Oberfläche weiter. Dieses "Crosscompiling" (allerdings nicht innerhalb der Windows Umgebung gemacht, sondern mit einem separaten Linux-Rechner [checke ich als Anfänger nämlich nicht so richtig]) funktioniert - dank eurer Hilfe auch super (Danke!).
Jetzt wollte ich mein weiter entwickeltes Programm auch mal wieder für "Windows" kompilieren (auf einem separaten Rechner) was aber diverse Probleme macht.
Sowohl auf Linux als auch auf Windows ist dieselbe Version (Lazarus 1.2.4).

Es treten aber beim Programmstart immer wieder "External: SIGSEGV" Fehler auf. Das Programm arbeitet mit zwei Formularen. Ursache ist wohl, dass unter Windows Proceduren des Formulars2 von Formular1 aufgerufen werden. Wahrscheinlich durch das Auslösen eines Memo-enter-Ereignis ganz zu Beginn des Programms, wo das Formular2 offenbar noch nicht bereit ist, Ereignisse abzuarbeiten. (Bitte mine Ausdrucksweise zu entschuldigen). Man kann jedenfalls die "SIGSEGV"-Fehler ausmerzen, wenn man dafür sorgt, dass alle Ereignisaufrufe, die unmittelbar bei Programmstart vom Forumlar1 aus zum Formular2 gemacht werden, verhindert werden. Dass mit dem Weglassen dieser Procedur-Aufrufe das Programm leidet liegt auf der Hand.

Natürlich hat niemand von Euch wahrscheinlich gerade die richtige Glaskugel zur Hand, aber vielleicht hat ja jemand eine spontane Idee, die mir weiterhelfen kann. Denn es ist bemerkenswert, dass der Programmcode unter Linux völlig fehlerfrei läuft!

Vielleicht hilft auch das weiter: Beim Beenden - eigentlich NACH dem Beenden - des Programms, und nach dem "Ausschalten" der SIGSEGV"-Fehler verursachenden Proceduren und Textzeilen [form2.irgendwas.tu_was] , wenn also das Programm - mit Abstrichen bei manchen Funktionen - problemlos läuft und gelaufen ist, erscheint folgende Fehlermeldung:

Error

Heap dump heaptrc unit
184341 memory blocks allocated:33653651/34159312
184341 memory blocks feed : 33653651/34159312
0 unfreed memory blocks: 0
True heap size:2326528 (80 used in System startup)
True free heap:2326448

Ich weiß, meine Fehlerbeschreibung ist mangelhaft! Sorry.
Aber ich suche schon tagelang nach Fehlern; vielleicht kann mir ja jemand von Euch einen entscheidenden "Schubser" bzw. Hinweis geben, damit ich irgendwie weiter komme.

Aliobaba

[Michl]

Die Meldung ist etwas verwirrend (Titel "Error" sollte ersetzt werden, könnte man im Bugtracker mal anmerken), doch das ist nicht wirklich eine Error-Meldung. Das angezeigte Fenster ist die Meldung von Heaptrc. Heaptrc dient zur Findung von Speicherlecks und kann in den Projekteinstellungen -> Debuggen -> Andere Debugger-Optionen -> Heaptrc-Unit verwenden aus- und angestellt werden.
Man kann die Unit auch per Hand einfügen. Diese sollte dann aber vor allen anderen Units in der Uses-Klausel stehen, da sie sonst Probleme macht (ob das bei Dir der Fall ist, kann ich allerdings nicht sagen).

Ich würde daher in den Projekteinstellungen schauen, ob Heaptrc ausgeschaltet ist. Wenn ja, dann müsstest Du mal schauen, ob Du irgendwo in einer Uses-Klausel heaptrc eingebunden hast (sollte, wenn händisch eingefügt, als erste Unit in der "Projekt".lpr zu finden sein).

[Aliobaba]

Und wieder einmal:
Danke, Michl!!!

Die Meldung ist weg.

Noch jemand eine Idee, warum sich das "Windows-Compilat" bei gleicher Programmversion anders verhält als das "Linux-Compilat"?
Offenbar werden vom "Windows-kompilierten" Programm" einige Proceduren der Form2 "zu früh?" aufgerufen, beim Linux-kompilierten Programm ist das anders.

Aliobaba

Wenn man den Programmablauf verfolgt, dann ist
Application.initialize; fehlerfrei (.lpr)
auch Form1.create; läuft ohne Fehler durch (Unit1)
dann wieder in der ".lpr"
hier fällt auf, dass
Application.createForm (TForm1,Form1) zweimal hintereinander mit (F8) angezeigt wird, wobei beim zweitenmal dieser SIGSEGV fehler kommt.

Und falls es jemand interessiert. Da:
http://www.mymemorydb.n-bay.de/DL/MyMem ... _Linux.zip
ist die kompilierte Linux-Version. (Beta!)

[Soner]

Dann erstelle manuell 2. Formular in OnCreate des ersten Formulars, dann weißt du sicher ob einige FUnktionen schon vorher aufgerufen werden.
Ich lasse nur Hauptformular automatisch erstellen, alle anderen Formulare und Module entweder beim Bedarf oder in Oncreate des Hauptformulars.

[Michl]

Wieso schreibst Du denn so klein, wie Du den Fehler erzeugt bekommst, da bricht man sich ja die Augen.

Klingt auf jeden Fall interessant, sowas habe ich noch nicht hinbekommen. Hast Du mal versucht ein Minimalbeispiel zu erstellen oder eine Kopie Deines Projektes soweit zu minimieren, bis hauptsächlich nur noch das Fehlverhalten sichtbar ist?! Falls Du dann immer noch nicht siehst, woran das liegt, könntest Du das Beispiel hier hochladen. Ansonsten wären weitere Tips eher spekulativer Natur.

[Aliobaba]

Hallo und Danke an Soner und Michl,

.... habe schwere Zeiten hinter mir
Aber euere Hinweise brachten den Durchbruch!

Ich beschreibe kurz das Problem; vielleicht haben auch andere später einmal etwas davon:

Zu Beginn des Programms schließe ich erstmal alle offenen Datenbanken, die ich in der Entwicklungsumgebung offen lasse ->
-> form1.ZConn1.Connected := False;

Dies machte ich in der ".lpr" Datei nach dem Befehl "Application.CreateForm(TForm1, Form1)"; - > "Application.Run;".
Die anderen Formulare erstellte ich auch zunächst in dieser ".lpr" - Datei bis ich den Hinweis von "Soner" bekam, weitere Formulare erst später erstellen zu lassen. Dies war für mich ein entscheidender Hinweis. Ich konnte den Programmlauf mit F8 besser verfolgen. Trotzdem war es für mich recht schwierig, schließlich rauszubekommen, dass der Programmablauf beim "Linux"-Kompilat anders ist als beim "Windows"-Kompilat:

Linux "arbeitet" offenbar die "lpr." Datei früher ab als Windows. Im kompilierten Windows-Programm springt die Programmausführung nach "Application.Run;" irgendwie später wieder in die ".lpr" Datei zurück als bei Windows. Dies führte dazu, dass auch die Datenbanken später erst (wieder) geschlossen wurden, also zu einem Zeitpunkt, wo sie eigentlich wieder geöffnet waren (und offenbleiben sollten!).

Ich bin wirklich Anfänger und kann es nicht beurteilen und weiß natürlich nicht, ob es gute Gründe dafür gibt, dass derselbe Programmcode unter Windows anders im Ablauf ist als unter Linux. Vielleicht wäre es sogar sinnvoll, dies zu vereinheitlichen.

Na,ja; hatte jedenfalls spannende Tage - und sicher wieder einiges gelernt

Gruß
Aliobaba

[wp_xyz]

Ich finde es generell keine gute Idee, Datenbanken zum Programmstart offen zu haben. Nach der Design-Arbeit werden bei mir Formulare/Datenmodule immer mit geschlossenen Datenbanken gespeichert, die Datenbank wird erst zur Laufzeit nach dem Erzeugen des Formulars oder Datenmoduls wieder geöffnet, wenn geprüft ist, ob alle Voraussetzungen erfüllt sind.