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. :(