avenger - Mo 20.07.09 22:04
Titel: Group Box Exception

---

habe ein seltsames Phänomen und weiss nicht wie ich es besiegen kann.

Ich habe ein ganz normale group box auf einem Formular. Sobald ich ein Label in diese group Box einfüge bekomme ich eine exception beim schliessen der Anwendung. Wenn ich die Group Box lösche dann dann tritt die exception nicht mehr auf. Und dies tritt auch nur auf meinem AMD (weiss nicht obs damit was zu tun hat auf) Auf meinem Intel Laptop läuft die Anwendung ainwandfrei. BEides XP Proffesional. Hat schonmal jemand sowas gehabt ?!

Xentar - Mo 20.07.09 23:13

---

Ich könnt wetten, dass das ganze nichts mit der Groupbox zu tun hat.

Vermutung:
Du überschreibst dir irgendwo den Speicher, und dies tritt nun zufällig bei der Groupbox auf.
Am liebsten passiert sowas bei (dynamischen) Arrays, wenn du dort zu weit (also über die Grenzen hinaus) läufst und dies überschreibst.

Aktivier in den Projektoptionen mal die Bereichsprüfung, erzeuge das Projekt neu, und lass das dann nochmal laufen.

avenger - Di 21.07.09 14:12

---

Hab ich gemacht, die Bereichsüberprüfung gibt mir auch keine Info. Aber auf meinem Laptop auf dem Delphi installiert ist tritt der Fehler ja auch nicht auf. nur auf dem Produktionsrechner auf dem die Anwendung laufen soll. Leider gibts da kein Delphi und somit kein Debugger :-(

Xentar - Di 21.07.09 14:17

---

Arbeitest du zufällig mit mehreren Threads?

Wenn ja, prüf mal, dass du keine nicht-synchronisierten Zugriffe auf gemeinsame Objekte / Formulare hast.

jaenicke - Di 21.07.09 14:21

---

Schreibe einmal in den Projektquelltext (Projekt --> Quelltext anzeigen) diese Zeile direkt nach dem begin:Die bewirkt, dass bei der Ausführung aus Delphi heraus Speicherlecks angezeigt werden. Da sollte beim Beenden, nachdem du möglichst alle Funktionen benutzt hast, keine Meldung kommen.

avenger - Di 21.07.09 14:21

---

Jetzt hab ich auch ne nicht nachvollziehbare Exception beim schliessen meiner Anwendung.
Hab mal einen Screenshot des Assmebler Codes angehangen. Vielleicht kann einer von euch daraus was erkennen ?!?

jaenicke - Di 21.07.09 14:23

---

Eine solche Meldung ist typisch, wenn ein Speicherproblem vorliegt. Entweder wie Xentar geschrieben hat wegen Threads oder wegen Pointerzugriffen oder ähnlichem. Deshalb versuche es am besten einmal mit der Zeile, die ich geschrieben habe, wenn du Threads ausschließen kannst.

avenger - Di 21.07.09 14:25

---

jaenicke hat folgendes geschrieben :

Schreibe einmal in den Projektquelltext (Projekt --> Quelltext anzeigen) diese Zeile direkt nach dem begin: Delphi-Quelltext 1: ReportMemoryLeaksOnShutdown := True; Die bewirkt, dass bei der Ausführung aus Delphi heraus Speicherlecks angezeigt werden. Da sollte beim Beenden, nachdem du möglichst alle Funktionen benutzt hast, keine Meldung kommen.

Da sagt er mir undefinierter bezeichner ReportMemoryLeaksOnShutdown ?!?

jaenicke - Di 21.07.09 14:29

---

avenger hat folgendes geschrieben :

Da sagt er mir undefinierter bezeichner ReportMemoryLeaksOnShutdown ?!?

Dann hast du noch eine sehr alte Version von Delphi, in der noch der alte langsame Speichermanager ohne eine solche Überprüfungsmöglichkeit drin ist (D2005, D7, oder noch älter). Da gibt es eine solche Funktion in Delphi noch nicht.

Da kannst du nur z.B. FastMM manuell installieren und in das Projekt einbauen.

avenger - Di 21.07.09 14:32

---

Ja ich nutze D7.....

Dann wer ich das jetzt mal mal nach FastMM googlen !

avenger - Di 21.07.09 15:24

---

Bräuchte nochmal deine Hilfe mit FastMM !!

Hab das jetzt soweit eingebunden und bekomme bei starten der Anwendung den Fehler das es nicht installiert werden konnte und es erste unit in der Projectdatei stehen muss.

Meine Projectdatei wurde ja von Delphi erzeugt, was muss ich ändern damit FastMM die Allererste unit in der Projectdatei ist ?!?

Xentar - Di 21.07.09 15:26

---

avenger hat folgendes geschrieben :

Meine Projectdatei wurde ja von Delphi erzeugt, was muss ich ändern damit FastMM die Allererste unit in der Projectdatei ist ?!?

Diese dort eintragen, an erster Stelle?

Delete - Di 21.07.09 15:26

---

Öffne die *.dpr und trage FastMM4 als erste in der uses-Klausel ein.

avenger - Di 21.07.09 15:37

---

Anscheinend bin ich dafür zu doof, der Compiler lässt mich das Project dann nicht mehr erzeugen. Hier ist der Projectquellext !!



Moderiert von Narses: Delphi-Tags hinzugefügt

Xentar - Di 21.07.09 15:40

---

Sieht richtig aus..
Problembeschreibung? Fehlermeldung?
Dem Compiler sollte das egal sein -> das Projekt kannst du immernoch kompilieren.

jaenicke - Di 21.07.09 15:42

---

Du hast FastMM4 doppelt in der uses drin. Du musst die nicht dem Projekt hinzufügen (letzte Zeile der uses), sondern nur ggf. das Verzeichnis dem Bibliothekspfad hinzufügen, in dem die Unit FastMM4 liegt. Dann reicht die erste Zeile der uses auch. ;-)

(Lösche einfach die letzte Zeile der uses und vergiss das Semikolon in der Zeile vorher dann nicht.)

avenger - Di 21.07.09 15:44

---

Xentar hat folgendes geschrieben :

Sieht richtig aus.. Problembeschreibung? Fehlermeldung? Dem Compiler sollte das egal sein -> das Projekt kannst du immernoch kompilieren.

Fehler: Bezeichner redefiniert "FastMM4"

Der Compiler zeigt diese zeile Rot:
FastMM4 in 'FastMM4.pas';

---Moderiert von Narses: Beiträge zusammengefasst---

jaenicke hat folgendes geschrieben :

Du hast FastMM4 doppelt in der uses drin. Du musst die nicht dem Projekt hinzufügen (letzte Zeile der uses), sondern nur ggf. das Verzeichnis dem Bibliothekspfad hinzufügen, in dem die Unit FastMM4 liegt. Dann reicht die erste Zeile der uses auch. ;-) (Lösche einfach die letzte Zeile der uses und vergiss das Semikolon in der Zeile vorher dann nicht.)

Danke, mit kleinen schritten zum Ziel :-)

avenger - Di 21.07.09 15:55

---

So FastMM läuft schonmal. So nun wieder zum Ursprungsproblem. Folgende Meldung gibt mir FastMM nun beim schliessen der Anwednung. Sieht für mich aus als mache ich irgendwas grundsätzliches falsch, aber so ist das bei Blutigen anfängern :-)

bin für jeden Tip dankbar !

jaenicke - Di 21.07.09 16:01

---

Aaalso:
Erstens sehe ich da, dass es sich um ein Formular und Teile davon handelt. Zweitens, dass da eine kritische Sektion und eine Zugriffsverletzung dabei sind.

Folgerung:
Es tritt eine Zugriffsverletzung auf, und infolgedessen wird das Formular nicht freigegeben. Das Freigeben fehlt also vermutlich gar nicht.

Da dort eine kritische Sektion vorkommt, sind wir wieder beim Thema Multithreading. Ich sagte ja, dass das mit dem Speicherleck und so erst nach dem Überprüfen von Threads gemacht werden sollte. Denn Threads wie Xentar ja meinte, wären auch sehr typisch für einen solchen Fehler und sind oft leichter zu prüfen als Speicherlecks.

Deshalb erneut Xentars Frage:
Benutzt du Multithreading? Und greifst du auf Formularelemente aus dem Thread zu? Vielleicht fälschlicherweise ohne Synchronisierung?

avenger - Di 21.07.09 16:08

---

Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.

nein, ich nutze kein Multithreading !
Ich eine Komponente die Daten aus einem Automatisierungssystem zieht und zyklich über einen Timerinterval aufgerufen wird.

jaenicke - Di 21.07.09 16:11

---

Dann aktiviere einmal die in der Notiz unten in der Meldung angegebenen Optionen in der .inc Datei, vielleicht ist dann mehr zu sehen.

Und vielleicht sagt auch BenBE noch etwas dazu, wie das am besten zu debuggen ist. :mrgreen: