XE4 Probleme beim Beenden der Anwendung - DoneMonitorSupport

[Alex_ITA01]

Habe ich probiert mit dem Debuggen nach dem .End
Da lande ich in der System.pas in der procedure _Halt0;

Da ist eine While True do Schleife drinne, die ich aber nicht genau verstehe.
In irgendwelche finalization Abschnitte komme ich leider gar nicht.
Es sind auch Fremdkomponenten (TMS) im Einsatz und ich weiß gar nicht, welche Unit denn überhaupt alles finalization Abschnitte nutzt...

Hast du noch eine Idee, was ich machen könnte bzw. wie ich über das CPU Fenster herausfinden kann, welcher Thread vielleicht hängt?

Ein WaitFor ist bei uns nicht im Einsatz.

Gruß

[baumina]

Zum Eingrenzen solch seltsamer Fehler kommentiere ich immer möglichst viele Dinge einfach aus. In deinem Fall würde ich versuchen die Threads mal komplett rauszunehmen.

[Alex_ITA01]

Hab gefunden in welchen finalization Abschnitt er hängt.
System.SysUtils -> DoneMonitorSupport -> CleanEventList -> repeat until AtomicCmpExchange(EventCache[I].Lock, 1, 0) = 0;

Dort bleibt er ewig hängen.
Uwe Raabe hatte dazu hier schonmal was geschrieben:
http://stackoverflow.com/questions/1...upport-on-exit

Ich vermute TMS benutzt das Objekt TMonitor, da ich es definitiv nicht nutze.

Gibt es da eine Info, was man genau machen kann / sollte?

Werde TMS mal kontaktieren.

Die System.SysUtils.pas kann man ja leider nicht ändern und neu compilieren oder gibts da doch ein Weg dafür?

// Neu:
Ich habe das ganze jetzt mal mit 64bit probiert und siehe da, es geht.

Habe zwei Screenshots angefügt, wo man sieht, wie das Array "SyncEventCache" aussieht zwischen 32 und 64 bit.

Da sieht man auch, das es dann eben bei 64bit geht, weil da keine "1" in einem der Events steht.
Hoffe hier kann jemand helfen?!

Gruß
Alex

[Alex_ITA01]

Hallo zusammen,
ich muss das Thema nochmal auffrischen, weil es für mich hier immernoch keine Lösung gibt.
Einen entsprechenden QC habe ich gemacht aber ich kann und darf meine Anwendung leider nicht dort posten (diese würde wahrscheinlich auch den Rahmen des Supportes sprengen -> >700000 Zeilen, TMS gekauft und voll im Einsatz usw.).

Gibt es denn irgendeine Möglichkeit, entweder die vorhandene Funktion "DoneMonitorSupport" in der System.SysUtils.pas zu ändern oder das man diesen MonitorSupport abschaltet? Meine Anwendung funktionierte unter D2009 ja auch. Wenn ich wenigstens ein Hinweis darauf bekommen würde, welches Event dort nicht freigegeben ist, dann könnte ich ja auch danach suchen aber so...

Hoffe hier kann mir noch jemand weiter helfen.

Danke und Gruß
Alex

[Uwe Raabe]

TMS Components verwendet meines Wissens kein TMonitor. Allerdings wird es in XE4 an deutlich mehr Stellen in der VCL verwendet als noch in D2009 (sogar in BDE.DBTables). Es kann also durchaus sein, daß es sich um ein ganz normales RTL/VCL-Objekt handelt, daß in XE4 jetzt den Monitor-Support nutzt. Wenn du eine dieser Instanzen nicht freigibst, dann kann genau dieses Verhalten auftreten.

Du kannst ja mal probeweise den MonitorSupport überwachen, in dem du folgende Unit einbindest:

Delphi-Quellcode:

unit WrapMonitorSupport;

interface

implementation

var
  SaveMonitorSupport: PMonitorSupport;

function NewSyncObj: Pointer;
begin
  result := SaveMonitorSupport.NewSyncObject;
end;

procedure FreeSyncObj(SyncObject: Pointer);
begin
  SaveMonitorSupport.FreeSyncObject(SyncObject);
end;

function NewWaitObj: Pointer;
begin
  result := SaveMonitorSupport.NewWaitObject;
end;

procedure FreeWaitObj(WaitObject: Pointer);
begin
  SaveMonitorSupport.FreeWaitObject(WaitObject);
end;

function WaitOrSignalObj(SignalObject, WaitObject: Pointer; Timeout: Cardinal): Cardinal;
begin
  result := SaveMonitorSupport.WaitOrSignalObject(SignalObject, WaitObject, Timeout);
end;

const
  MonitorSupport: TMonitorSupport = (
    NewSyncObject: NewSyncObj;
    FreeSyncObject: FreeSyncObj;
    NewWaitObject: NewWaitObj;
    FreeWaitObject: FreeWaitObj;
    WaitOrSignalObject: WaitOrSignalObj;
  );

initialization
  SaveMonitorSupport := System.MonitorSupport;
  System.MonitorSupport := @MonitorSupport;
end.

Einfach BreakPoints in die Wrapper setzen und schauen, wer die aufruft.

[Alex_ITA01]

Hallo Uwe,
ich habe mich selber schonmal in die Funktion "TMonitor.Enter" debuggt und geguckt, wer das alles aufruft.
Ich bin dann schließlich auf TThread gestoßen, der beim Create ein Objekt "ThreadLock" erstellt, welches dann mit TMonitor.Enter und TMonitor.Exit genutzt wird. Und im Destructor wird dieses Objekt dann wieder freigegeben.

Das komische ist ja, dass es nicht immer auftritt dieser Fehler.
Mal funktioniert es, mal bleibt er hängen in der Schleife.

Bei einem Kollegen, der den gleichen Quelltext compiliert (auf einem anderen PC), funktioniert es komischerweise nie. Irgendwie kommt mir das sehr komisch vor. Wenn ich eine Exe habe, mit der es gerade mal funktioniert, dann funktioniert es auch immer mit dieser Exe. Wenn mein Kollege diese funktionierende Exe nimmt und bei sich auf dem PC testet, funktioniert es bei ihm auch. Das hört sich doch für mich nach irgendeinen Compilerfehler an, der in die Exe rein compiliert wird oder nicht?

Gruß
Alex

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