AV beim beenden

[Meta777]

Hallo DP :hi:

kennt jemand das Problem das beim Beenden eines Progs sporadisch Access-Violations auftreten?
Wir ham grad solche Probleme und es nervt, da man teilweise die Progs dann übern TaskMgr killen muss...
Da dieses Problem auch relativ selten auftritt läßt es sich nur schwer mit laufenden Debugger reproduzieren.
Unser letzter Versuch dies zu beheben war ein Halt() in MainForm.Destroy, jedoch ohne Erfolg... :(

Wenn ihr Tipps oder sogar Lösungen anbieten könnt - immer her damit :nerd:

Shalom

Edit: Ist natürlich Win32.... :oops:

[RavenIV]

Bei AVs gibt es meiner Erfahrung nach zwei Gründe:
- es wird auf Elemente/Objekte zugrgriffen, die schon längst zerstört sind
- es werden bei Programmende nicht alle Objekte wieder sauber freigegeben

Hast Du aber Runtime-Errors, dann ist meistens das (nicht eingebundene) ShareMem daran schuld.

[Khabarakh]

Es handelt sich nicht wirklich um eine .Net-Anwendung, oder?

[Meta777]

Zitat:

Zitat von RavenIV

Bei AVs gibt es meiner Erfahrung nach zwei Gründe:
- es wird auf Elemente/Objekte zugrgriffen, die schon längst zerstört sind
- es werden bei Programmende nicht alle Objekte wieder sauber freigegeben

Hast Du aber Runtime-Errors, dann ist meistens das (nicht eingebundene) ShareMem daran schuld.

Also nach dem AVs kamen auch immer eine Runtime Error Meldung. Was genau meinst du mit nicht eingebundenen ShareMem?? Soll die Unit ShareMem eingebunden werden, oder wie? Wofür ist die gut. Ok, Share Mem (Speicher teilen) sagt über sich selbst schon einiges. Aber warum brauchen wir das bei uns?

@Khabarakh:
War 'n Verklicker. Ist natürlich Win32.

[Surrounder]

Mir ist so was früher immer bei Timern passiert. Wenn die sich selber wieder starten dann kann es beim beenden mächtig rappeln.

Schau dir mal den madexcept an, der hat mir da immer geholfen um zu finden wo es passiert

[RavenIV]

Sobald Du irgendwas mit DLLs machst und parameter übergibst, ist es empfohlen, in allen .dpr die ShareMem als erste Unit einzubinden.

[Meta777]

Zitat:

Zitat von RavenIV

Sobald Du irgendwas mit DLLs machst und parameter übergibst, ist es empfohlen, in allen .dpr die ShareMem als erste Unit einzubinden.

Achso, aber das trifft doch nur zu wenn man String-Parameter benutzt, oder? Das ist aber bei uns nicht der Fall. Wir benutzen zwar DLLs aber die sind nicht von uns...

[Christian Seehase]

Moin Meta777,

ausser den genannten Tips solltest Du in den Projektoptionen auch einmal die Bereichsprüfung aktivieren.
Das Problem kann auch auftreten, wenn Grenzen von Arrays überschritten werden.

[Meta777]

Hallihallo....

Wir haben nun folgende Lösung umsetzen müssen:

Delphi-Quellcode:

function daForceSelfTerminate: Boolean;
//2006_09_14 Code der nach daForceSelfTerminate() steht wird nicht ausgeführ
//wenn daForceSelfTerminate() TRUE zurück gibt...
var
  h: Cardinal;
begin
  Result := False;
  h := OpenProcess(PROCESS_TERMINATE, False, GetCurrentProcessId);
  if (h <> 0) then
    Result := TerminateProcess(h, 0);
end;

Allerdings gefällt mir diese Lösung nicht wirklich...
Ich habe Bedenken dass es unter älteren Windows-Versionen (Win9x/ME) vielleicht Probleme mit der Speicherbereinigung geben könnte?
Unter NT/2K/XP hoffe ich das so etwas nicht der Fall ist.
Könntet ihr mir jedoch sagen ob meine Befürchtungen begründet sind oder eher nicht?

Vielen Dank

Shalom & Gottes Segen :wink:

PS: Das Ausschalten der Bereichsprüfung hatte unangenehme folgen, da einige Routinen (unter anderen Hagen's DEC und Zeichenmethoden) nicht mehr liefen... Also haben wir die Bereichprüfung wieder deaktivieren müssen... :?

[SirThornberry]

anstelle von OpenProcess kann man auch gleich GetCurrentProcess nutzen. Aber wie bereits weiter oben erwähnt wird kommen AV's beim beenden in aller Regel zustande weil auf bereits zerstörte Elemente zugegriffen wird. Wenn man zum Beispiel eine Server oder Client-Komponenten hat und im Destroy die Verbindung trennt und dann darauf in Events reagiert kann es schnell zu AV's kommen (wenn man zum Beispiel schon dinge frei gegeben hat welche in einem OnChange angesprochen werden). Auch bei Listviews etc. kommt es schnell mal vor wenn man das OnChange nutzt. Denn wenn das Listview frei gegeben wird und nochmal gecleart wird kommt man in's onChange wo man auf dinge zugreift die zu dem Zeitpunkt wohlmöglich schon zerstört sind.