access violation in Menus.SetWindowHandle

[iphi]

Hallo,

ich kämpfe gerade mit einer Access Violation, die beim Schließen meines Programmes erst nach Ablauf von OnClose und OnDestroy auftritt.
Mit den Debug-DCUs habe ich festgestellt, dass das in Menus.pas passiert und zwar in SetWindowHandle:

Delphi-Quellcode:

procedure TMenu.SetWindowHandle(Value: HWND);
begin
  FWindowHandle := Value;
  UpdateImage;
  { When menus are created, if BiDiMode does not follow the parent,
    main menu headers are displayed in reversed order. Changing BiDiMode
    twice fixes this. }
  if (SysLocale.MiddleEast) and (Value <> 0) then
    if FParentBiDiMode then
      ParentBiDiModeChanged
    else
      AdjustBiDiBehavior;
end;

Irgendwann ist FWindowHandle nicht mehr verfügbar und dann kracht es in der ersten Zeile bei der Zuweisung von value, vermutlich wenn das Hauptmodul aus dem Speicher geworfen wird!?!

Was macht diese Routine denn beim Schließen der Applikation überhaupt? Die wird nach OnDestroy noch mehrfach vor dem Crash aufgerufen.

Wie könnte ich zurückverfolgen, wer der ursprüngliche Übeltäter ist?

Bin für jeden Tipp dankbar, da ich mit meinem Latein am Ende bin!!!

[himitsu]

Wie genau sieht denn die Fehlermeldung aus?
(du wirst es nicht glauben, aber Strg+C in der Fehlermeldung und dann hier als Text einfügen Strg+V)

Und den Stacktrace kennst du? (den kann man übrigens auch Multiselekt markieren und kopieren)

Wenn es wirklich in der ersten Zeile knallt, dann hat jemand diese Methode aufgerufen, obwohl das Objekt weg ist.
Zugriffsverletzung bei Adresse 000000xx -> der Objektzeiger ist NIL und der Aufrufer vergisst mit Assigned zu prüfen
Zugriffsverletzung bei Adresse xxxxxxxx -> der Objektzeiger ist IRGENDWAS und jemand hat vergessen die Variable auf NIL zu setzen, als dasObjekt freigegeben wurde

bei NIL:
Man kann extern den Bugfix machen (beim Aufrufer dieser Funktion) oder notfalls intern Bugfixen

Delphi-Quellcode:

if Assigned(Self) then Exit;

, aber vorzugsweise Ersteres.

[iphi]

Zitat:

Wie genau sieht denn die Fehlermeldung aus?

Code:

---------------------------
Debugger Exception Notification
---------------------------
Project VNWA.exe raised exception class EAccessViolation with message 'Access violation at address 00494646 in module 'VNWA.exe'. Write of address 00000038'. Process stopped. Use Step or Run to continue.

Zitat:

oder notfalls intern Bugfixen if Assigned(Self) then Exit;

Das habe ich probiert, aber es hilft nicht, weil der Bug anscheinend gar nicht da auftritt, sondern schon viel früher! Wie ich jetzt mittels Breakpoints und Einzelschritt gemerkt habe, ist an dieser Stelle der Debugger schon völlig aus dem Tritt, d.h. er springt z.B. auf leere Codezeilen, und das bereits bevor die Access Violation ausgelöst wird. Der Speicher ist also schon korrupt. :-(

Zitat:

Und den Stacktrace kennst du?

Du meinst den Call-Stack!?
Der ist hier:

Code:

 
TMenu.SetWindowHandle(0)
TCustomForm.WMDestroy((2, (0, 0, 0, 0), 0))
TControl.WndProc((2, 0, 0, 0, 0, 0, 0, 0, 0, 0))
TWinControl.WndProc((2, 0, 0, 0, 0, 0, 0, 0, 0, 0))
TCustomForm.WndProc((2, 0, 0, 0, 0, 0, 0, 0, 0, 0))
TWinControl.MainWndProc((2, 0, 0, 0, 0, 0, 0, 0, 0, 0))
StdWndProc(791598,2,0,0)
TCustomForm.DestroyWindowHandle
TCustomForm.Destroy
TComponent.DestroyComponents
DoneApplication
DoExitProc
@Halt0
VNWA

Was kann ich daraus ablesen?

[HolgerX]

Hmm..

Zitat:

Zitat von iphi (Beitrag 1388377)

Wie ich jetzt mittels Breakpoints und Einzelschritt gemerkt habe, ist an dieser Stelle der Debugger schon völlig aus dem Tritt, d.h. er springt z.B. auf leere Codezeilen, und das bereits bevor die Access Violation ausgelöst wird. Der Speicher ist also schon korrupt. :-(

Das kenne ich,wenn in der pas Datei gemischte Zeilenumbrüchen vorhanden sind ( mal Windows #13#10, mal nur #13), dann landet der Debugger in der falschen Zeile.

Jedoch solltest Du das daran sehen, das die (bei D6) blauen Compiler-Punkte auch total auf den falschen Zeilen liegen.

Es kann auch daran liegen, das der Linker eine andere DCU verwendet, wie die vom Debugger verwendete PAS...

(Alles nur so Ideen... ;) )

[hoika]

Hallo,
wie Du schon erkannt hast, hat das nichts mit Menus.pas zu tun.

Benutze FastMM4.
Arbeitest du mir Interfaces? Vielleicht wird ein Objekt zweimal freigegeben.

Du kannst das debuggen, indem Du den kompletten Code auskommentierst und dann schrittweise wieder reinnimmst.
So solltest Du die Codestelle finden, die Dein Menu oder Form kaputt macht.

[iphi]

Zitat:

Das kenne ich,wenn in der pas Datei gemischte Zeilenumbrüchen vorhanden sind ( mal Windows #13#10, mal nur #13), dann landet der Debugger in der falschen Zeile.

Aha, habe wieder was gelernt! Das ist mir bisher nicht aufgefallen.

Zitat:

Benutze FastMM4

Das benutze standardmäßig immer, um Speicherlecks möglichst sofort zu bemerken. Ist immer aktiv. FastMM4 schlägt nicht an.

Zitat:

Du kannst das debuggen, indem Du den kompletten Code auskommentierst und dann schrittweise wieder reinnimmst.
So solltest Du die Codestelle finden, die Dein Menu oder Form kaputt macht.

Das ist leider nicht so einfach. Im Laufe der Jahre ist der Code auf ca. 10MB Quellen gewachsen. Und das Problem tritt abhängig von der Bedienung auf. Ich habe schon ziemlich im Code gewütet, konnte aber bislang den Fehler noch nicht isolieren.

[himitsu]

Seit Delphi 2006 ist FastMM direkt im Delphi enthalten, allerdings eine etwas abgespeckte Version,
die am Ende nur nicht freigegebenen Speicher melden kann, wenn man eine Variable setzt.
ReportMemoryLeaksOnShutdown

Beim normalen FastMM mußt du erst in der INC die erweiterten Funktionen aktivieren.

Ob FastMM hier selbstständig den Fehler meldet, weiß ich nicht, aber zumindestens sollte man es dazu bringen können, Einem zu sagen von wem und wo diese Speicherstelle als letztes Freigegeben wurde.

[iphi]

Zitat:

Beim normalen FastMM mußt du erst in der INC die erweiterten Funktionen aktivieren.

Hab ich gemacht, keine Meldungen.

Habe aber etwas merkwürdiges anderes gefunden.
Wenn ich ein Menu-Item auf visible stelle, dann tritt der Fehler auf, stelle ich das Menu-Item auf invisible, dann nicht.
Es scheint also der Speicherbereich des Menu-Item betroffen zu sein. Kann mir das irgendwie weiterhelfen?

[p80286]

Nö eigentlich nicht. Dann erfolgt der Schreibvorgang, der fehlerhaft ist, auf gültigen Speicher. Ob es aber die richtige Stelle ist, steht auf einem ganz anderen Blatt. Irgendwo hast Du Dir selbst den Speicher unter den Füßen selbst weggezogen bzw. wuschig gemacht. Sind alle Prüfungen (Bereich etc.) aktiviert?

es muß übrigens nicht zwingend die letzte Änderung der Sourcen sein.

Gruß
K-H

[iphi]

Zitat:

Sind alle Prüfungen (Bereich etc.) aktiviert?

Ja, mach ich standardmässig immer.

Zitat:

es muß übrigens nicht zwingend die letzte Änderung der Sourcen sein.

Ich weiß. Der Fehler ist schon seit mindestens 2 Jahren drin, hat sich aber erst jetzt manifestiert. Hab ich schon überprüft. :(

[Bernhard Geyer]

Ich hatte auch mal (vor sehr langer Zeit) einen sehr komischen Fehler (Zugriff auf Screenobjekt das schon freigegeben wurde) beim beenden des Programms.
Es zeigte sich das die beim beenden der Anwendung automatisch geschlossene DB-Verbindung schuld war beim schließen der Verbindung hin und wieder meinte eine Wartecurser einzublenden.
Hab die Aufräumarbeiten in OnCloseQuery gelegt und schon war das Probelm gelöst.

Verwendest du immer noch D6 wie in deinem Profil angegeben?

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1388414)

Verwendest du immer noch D6 wie in deinem Profil angegeben?

https://www.embarcadero.com/de/products/delphi/starter
Aber bissl was wäre dann zu beachten
* es gibt ein paar Bugs weniger
* Andere sind neu
* Unicode, also mit Delphi 2009 wurde Dlphi umgestellt
* einige Funktionen wurden in andere Units verschoben
* Units wurden umbenannt und die Standardnamespaces werden nicht automatisch in alte Projektdateien eingefügt (z.B. SysUtils > System.SysUtils)

[iphi]

Zitat:

Verwendest du immer noch D6 wie in deinem Profil angegeben?

Inzwischen verwende ich D7. Als D8 rauskam, hab ich das mal ausprobiert und war mit der Performance sehr unglücklich. Ich bin nach wie vor von der Compiliergeschwindigkeit von D7 begeistert. Ich kenne keinen anderen Compiler+Linker, der so schnell ist.

Das hat mir auch bei meinem Problem weitergeholfen. Ich habe nach und nach immer größere Teile meines Codes auskommentiert und den Übeltäter so eingekreist, aber noch nicht endgültig identifiziert.

Im OnResize Eventhandler des MainForm mache ich ziemlich viel, wie Grafiken aufbauen und Objekte neu anordnen. Wenn ich den Handler gleich wieder verlasse, ist der Spuk vorbei.

Dabei ist mir aufgefallen, dass OnResize nochmal NACH OnClose ausgelöst wird. Warum eigentlich? Das macht doch gar keinen Sinn!

Wenn ich den OnResize ausschließlich nach OnClose blockiere, ist der Spuk auch vorbei. Der Handler selber scheint sauber zu sein.

[himitsu]

D8 und 2005 waren aber auch grauenhaft.
D2006 war wieder benutzbar.

OnResize wird öfters aufgerufen, als man denkt.
Ich hatte letzten Donnerstag einen Fehler gesucht und war überascht, dass OnResize 5 Mal aufgerufen wird, wenn ich nur die Caption der Form ändere. :wall:
In meinem Fall konnte ich da viel beschleunigen, wenn ich Self.Height mit NewHeight vergleiche und dann nichts mache.

Im Code der VCL und von DevExpress wird DoResize an sehr vielen Stellen aufgerufen.

Also bei dir hilft dann schon ein

Delphi-Quellcode:

if csDestroying in ComponentState then Exit;

, aber das mit Width/Height solltest du auch mal prüfen.

[iphi]

Zitat:

Also bei dir hilft dann schon ein if csDestroying in ComponentState then Exit;

Genau, so hab ichs gemacht.

Zitat:

aber das mit Width/Height solltest du auch mal prüfen.

Gute Idee, danke!

P.S. Ich konnte den Fehler isolieren. Ich halte mich für komplett unschuldig! Den Quatsch macht sowohl D6 als auch D7. Ich öffne einen separaten Thread mit einem kurzen Beispielcode.