![]() |
Seltsame Speicherschutzverletzung
Hallo,
ich ärgere mich im Moment mit einer nicht lokalisierbaren Speicherschutzverletzung rum. Villeicht hat wer eine Idee? Beim Öffnen eines Fensters kommt eine Spreicherschutzverletzung. Beim Anhalten des Programms in der IDE ist der Debugger irgendwo im Assemblercode in einer Methode "Finddynamethode". Setze ich in dem Fenster einen break z.B. bei Formactivate, dann kommt der Fehler nicht. Der Fehler kommt auch nicht notwendigerweise bei jedem Öffnen des Fensters. Wenn ich die 'Exception abfange dann zeigt er als verursachendes Object TDragControlObjectEx an. In diesem Fenster sind aber keine Drag Drop Mechanismen aktiviert. Ich finde auch keinen Ansatzpunkt diesen Fehler mit einer Brachialmethode try exept abzufangen, da er nach Formactivate und vor dem ersten Ereignis in der Form (Timer) eintritt. Hat wer eine Idee, wie ich an diesen Fehler herankomme? Ergänzung Delphi 2010 und Windows7. Gruß Peter |
AW: Seltsame Speicherschutzverletzung
Hast du einmal versucht FastMM im Fulldebugmode zu benutzen? Oder madExcept?
Wegen der Methode im Assemblercode: Benutzt du irgendwelche überschriebenen Methoden? Hast du einmal alle Events herausgeworfen? |
AW: Seltsame Speicherschutzverletzung
Kannst Du ein Testprojekt anhängen wo dieser Fehler reproduzierbar ist?
|
AW: Seltsame Speicherschutzverletzung
Das ist ja das Problem, wenn ich das eine Modul herauslöse und aufrufe, dann geht es.
Ich habe inzwischen auch ein bischen TMS im Verdacht (In dem Modul wird von TMS ADVStringGrid verwendet). Ich meine der Fehler kommt erst nach einem der letzten Update. Das Modul funktioniert eigentlich schon seit Jahren. Wenn ich nach der Fehleradresse suchen lasse, lande ich irgendwo im Assemblercode bzw. es kommt der Fehler nicht gefunden. Das Modul selbst wird aus einer Ablaufsteuerung als MDI aufgerufen. Testprojekt ist schlecht möglich, da das Projekt etwa 1,5 Millionen Quellzeilen hat und eine Reihe komerzieller Bibliotheken benötigt. Ich wollte nochmal Eurekalog probieren. Das läßt sich als Demo aber nicht nochmal installieren, wenn es bereits einmal installiert war. Kaufen möchte ich dieses Tool nicht, da es mir zu agressiv ist. (Ich hatte es ausprobiert und anschließend wieder deinstalliert. Da Delphi benötigte Units zwar einfügt aber nicht mehr entfernt, wenn sie nicht mehr benötigt werden, ist irgend eine automatisch eingefügte Unit von Eurekalog irgendwo in dem Programm verblieben. Die hatte dafür gesort, das meine Programme beim Kunden nach Ablauf der Evulationszeit reihenweise abstürzten, da sie von Eurekalog blockiert wurden). Das ist ein reines Datenerfassungsmodul. In Create setze ich einen Timer von 20 ms. Dieser nimmt dann Initialisierungen vor. Der Fehler tritt nach Activate und vor Auslösen des Timers auf. Dazischen läuft keinerlei Code im Fenster. Gruß Peter |
AW: Seltsame Speicherschutzverletzung
Dann wird der Fehler vermutlich ganz woanders liegen. Wahrscheinlich wurde bereits vorher irgendwo Speicher überschrieben oder ähnliches.
Das erklärt dann nämlich warum das Modul unabhängig funktioniert und warum du keine echte Fehlerstelle finden kannst. Hier hilft dir wirklich FastMM. Das zeigt dir solche Probleme in der Regel sehr gut an und ist noch dazu kostenlos. |
AW: Seltsame Speicherschutzverletzung
So nebenbei: Im Create würde ich den Timer nicht setzen, sondern im FormActivate.
Deaktivier den Timer doch mal und schau, ob das Problem immer noch auftritt. |
AW: Seltsame Speicherschutzverletzung
Zitat:
Der Timer soll auch nur die Unzulänglichkeit vom MDI umgehen, daß weder in onactivate noch onShow Fenstergröße und Position verändert werden kann. Er ist einmal aktiv und wird dann nicht mehr benötigt. Der Fehler tritt vor Aktivierung des Timers auf. FastMM werde ich heute abend mal probieren. (Wenn ich es richtig verstanden habe, ist FastMM doch schon in D2010 drin?) Gruß Peter |
AW: Seltsame Speicherschutzverletzung
Zitat:
Zitat:
|
AW: Seltsame Speicherschutzverletzung
Ich möchte das Thema nochmals hochbringen, vielleicht hat wer einen Tip.
Ich habe mich jetzt schrittweise mit dem Debugger durchgetastet und den Verursacher, wie erwartet in einer Fremdcomponente, gefunden. Der Fehler tritt in dem TMS Grid von TMS-Software auf (nur manchmal), wenn man die Maus über dem Grid bewegt. Als Ort wurde die Dragover-Behandlung des Grids isoliert. (Wird im Programm nicht verwendet.) Konkret tritt der Fehler bei der Anweisung
Delphi-Quellcode:
auf.
Accept := Source is TADVStringgrid;
EAcessviolation bei Adresse ... Lesen von Adresse FFFFFFD0. Hat wer einen Tip, was man machen könnte? Gruß Peter |
AW: Seltsame Speicherschutzverletzung
Existiert Source?
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz