access violation in Menus.SetWindowHandle

[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?