Seltsame Speicherschutzverletzung

[hanspeter]

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

[jaenicke]

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?

[daywalker9]

Kannst Du ein Testprojekt anhängen wo dieser Fehler reproduzierbar ist?

[hanspeter]

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

[jaenicke]

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.

[FredlFesl]

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.

[hanspeter]

Zitat:

Zitat von FredlFesl (Beitrag 1103609)

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.

Mit dem Timer hat das nichts zu tun.
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

[jaenicke]

Zitat:

Zitat von hanspeter (Beitrag 1103613)

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.

Naja, das macht man ja normalerweise auch nicht aus dem Formular heraus, sondern direkt nach dem Anzeigen an der Stelle im Code. Deshalb ist das keine Unzulänglichkeit, sondern denke ich eher ein ungünstiges Konzept bei dir. ;-)

Zitat:

Zitat von hanspeter (Beitrag 1103613)

FastMM werde ich heute abend mal probieren. (Wenn ich es richtig verstanden habe, ist FastMM doch schon in D2010 drin?)

Schon, aber ohne die Debuggingmöglichkeiten.

[hanspeter]

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:

Accept :=  Source is TADVStringgrid;

auf.

EAcessviolation bei Adresse ... Lesen von Adresse FFFFFFD0.


Hat wer einen Tip, was man machen könnte?

Gruß
Peter

[mkinzler]

Existiert Source?

[jaenicke]

Schon, aber TMS wird was dagegen haben, wenn jemand den postet. ;-)

Da wirst du wohl TMS fragen müssen. ;-)

[DeddyH]

Das sollte wohl eher heißen, ob die Variable Source Assigned ist. Das kann zu dem Zeitpunkt auch TMS nicht wissen :stupid:

[jaenicke]

Nun, immerhin stammt die Zeile ja aus deren Quelltext. ;-)

[Ralf Kaiser]

Schon mal hier news.tmssoftware.net (Support-Newsgruppen von TMS) nachgefragt?
(Allerdings muss man registrierter Kunde sein, da die Newsgruppen ein Kennwort erfordern)

[Daniel]

Zitat:

Zitat von hanspeter (Beitrag 1107148)

Hat wer einen Tip, was man machen könnte?

Wie hast Du die TMS-Komponenten reinkompiliert? Ich hatte hier mal ein Kundenprojekt am Wickel, welches bei einem "full build" auch alle eingebundenen Komponenten neu übersetzt hatte - allerdings mit den jeweiligen Compiler-Einstellungen des Projekts. Ähnliche wie die von Dir beschriebenen Effekte hatte ich mal mit den DevExpress-Komponenten. Das hat aufgehört, nachdem ich die Komponenten einmal wie vom Hersteller ausgeliefert kompiliert hatte (sei es über den Installer oder einfach nur über die Packages) und dann die Quellen aus dem Bibliothekspfad rausgenommen habe (reicht ja, wenn sie im Suchpfad sind, wenn man sie sich mal angucken muss oder möchte).

[stahli]

Ist denn Self in Ordnung?

[hanspeter]

Hallo,

ich habe diesen sporadisch auftretenden Fehler immer noch nicht gefunden.
Die Speicherschutzverletzung tritt meist dann auf, wenn ich in einem ADV Grid eine Row doppelt anklicke (Auswahl).
Alles was in diesem Grid mit Drag und Drop zu tun hat, steht auf false oder ist auskommentiert.
Ich hänge mal das Fehlerbild an, vielleicht hat doch noch wer eine Idee.

Gruß
Peter

[ConnorMcLeod]

Zitat:

Zitat von hanspeter (Beitrag 1107148)

Konkret tritt der Fehler bei der Anweisung

Delphi-Quellcode:

Accept :=  Source is TADVStringgrid;

auf.

EAcessviolation bei Adresse ... Lesen von Adresse FFFFFFD0.


Hat wer einen Tip, was man machen könnte?

Vor diese Zeile schreiben:

Delphi-Quellcode:

if (not Assigned(Source)) then exit;

[stahli]

Das glaube ich eben nicht.
Wenn Source = nil ist würde Accept immer False sein. Es sollte aber keine Fehlermeldung geben.
Meine Vermutung war deshalb, das das Objekt selbst (also Self) nicht mehr gültig (aufgelöst/überschrieben) ist.


EDIT: @hanspeter
Hast Du den Quelltext von dem Grid? Möglicherweise wird dort irgendwo BeginDrag aufgerufen, was Du anhand der Propertys nicht beeinflussen kannst.