XE4 Probleme beim Beenden der Anwendung - DoneMonitorSupport

[Uwe Raabe]

Zitat von Alex_ITA01:

Das hört sich doch für mich nach irgendeinen Compilerfehler an, der in die Exe rein compiliert wird oder nicht?

Hört sich eher nach ungültigen dcu-Dateien an. Machst du immer ein Build oder nur ein Compile? Es kann manchmal vorkommen, daß solche dcus entstehen, wenn man z.B. eine pas-Datei aus der Versionskontrolle zurücksetzt. Die vorher erstellte dcu ist dann neuer als die pas und schon passt was nicht zusammen. Es gibt aber noch dutzende andere mögliche Gründe für solche Effekte. Eine beliebte Quelle sind auch unterschiedliche Compiler-Einstellungen.

[Alex_ITA01]

Hallo Uwe,
was ich auch nicht verstehe ist, dass es bei einem 64 Build nie schief geht bei mir.
Wir machen eigentlich immer Umsch+F9 zum Projekt erzeugen und löschen per Batch Datei vorher alle alten DCUs.

Komisch ist irgendwie auch, dass immer in dem Haltepunkt "CleanEventList(SyncEventCache);" das SynchEventCache immer genau 3 Einträge drinne hat (nie mehr oder weniger) und manchmal ist das "Lock" von einem dieser Einträge auf 1 und damit hängt das ganze...

Irgendwie komisch. Aber ich bin ja nicht der einzige mit dem Problem so wie ich im Netz gelesen habe.
Kann man hier nicht irgendwie direkt an Embacadero ran treten und ein HotFix/Patch erfragen, damit es nicht hängen bleibt sondern einfach nur die Lock Eigenschaft abfragt auf 0 und nur dann freigibt...

Gruß
Alex

Edit:
Was mir jetzt noch grad dazu einfällt:
Ich ändere nichts am Quelltext und lösche per BatchDatei immer alle DCUs. Dann mache ich immer ein Rebuild mit Umschalt+F9 und die anschließend erzeugte Exe (32bit) funktioniert mal und mal nicht. Das kann doch gar nicht sein oder? Wenn die Exe dann mal funktioniert, dann funktioniert sie auch auf dem PC von meinem Kollegen. Das kann doch dann auch keine Einstellung am Compiler sein, diese ändere ich ja schließlich nicht

[Alex_ITA01]

Ich habe jetzt mal D2009 mit XE4 verglichen.
Das DoneMonitorSupport gibt es nämlich unter D2009 auch schon nur werden standardmäßig keine Events eingetragen (TMonitor.Enter -> TMonitor.GetEvent -> MonitorSupport.NewSyncObject).

Anbei mal ein Screenshot wo man den Unterschied im TThread deutlich sieht.
Das hat sich nämlich geändert zwischen den beiden Delphi Versionen.

(System.)Classes.pas

XE4: class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False);

Dort wird mit TMonitor.Enter/Exit gearbeitet

D2009: class procedure TThread.Synchronize(ASyncRec: PSynchronizeRecord; QueueEvent: Boolean = False);

Hier wird mit EnterCriticalSection(ThreadLock) und LeaveCriticalSection(ThreadLock) gearbeitet.

Schön wäre es jetzt natürlich, dass gleiche Verhalten wie unter D2009 wieder zu erzeugen.

Gruß
Alex

[Uwe Raabe]

Zitat von Alex_ITA01:

Schön wäre es jetzt natürlich, dass gleiche Verhalten wie unter D2009 wieder zu erzeugen.

Ich würde eher versuchen, die Instanzen zu finden, die unter bestimmten Bedingungen offenbar nicht freigegeben werden. Dann hast du das Problem beim nächsten Update nämlich auch nicht mehr. Grundsätzlich funktioniert DoneMonitorSupport ja, wenn wirklich alle Objekte, die TMonitor verwenden auch wieder freigegeben werden. Auch wenn du das jetzt irgendwie hin flickst, so daß der Hänger nicht auftritt, bleibt doch ein unangenehmer Beigeschmack - würde es zumindest bei mir.

[Alex_ITA01]

Klar, ich will es eigentlich auch richtig gelöst haben und nicht irgendwie gefuscht.
Das Problem ist ja, dass ich nicht genau weiß, wer alles TMonitor verwendet (scheinen ja in der neuen Delphi Version jede Menge Controls/Objecte zu sein) und wie ich vielleicht anhand der EventAdresse auf das Object schlussfolgern könnte.

Gruß
Alex

[baumina]

Als ich mit Threads angefangen habe, hatte ich die dollsten sporadischen Zugriffsverletzungen und sonstigen Mist. Deswegen tippe ich weiterhin darauf, dass dieses Verhalten von einem Thread ausgelöst wird. Gibt es für dich nicht die Möglichkeit diese Threads mal alle auszukommentieren, um zu schauen ob das Problem bleibt?

[jaenicke]

Ich habe das sehr einfach gelöst...
FastMM4 im FullDebugMode, Haltepunkt auf die genannte Schleife, per Assemblerfenster manuell aus der Schleife in DoneMonitorSupport raus und dann alle Speicherlecks geprüft, die FastMM4 gefunden hat.