access violation in Menus.SetWindowHandle

[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 von iphi:

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