Debugger hält beim Programmende in CPU-Fenster

[Codehunter]

Hallo!

Ich habe das Problem, dass seit einiger Zeit eines meiner Programme beim Beenden in der IDE das CPU-Fenster öffnet und dort an einem "Geister-Breakpoint" hält, jedoch keine Exception wirft. Siehe Bild unten. Vielleicht können die Experten da was rauslesen, ich habs jedoch nicht so mit Assembler.

Bei Recherche hier und mit dem Gockel habe ich Hinweise gefunden, die .DCU- und .DSK-Dateien zu löschen. Hat nichts geändert. An anderer Stelle wurde auf Non-ASCII-Zeichen im Pascalquellcode hingewiesen, doch laut Suchen-In-Dateien mit NP++ und Regex

Code:

[^\x00-\x7F]+

gibts sowas im betreffenden Projekt auch nicht. Ebenso wenig konnte ich Non-Standard-Linebreaks (!== $0C$0A) im Source finden.

Im unteren Teil sieht man Einträge wie "TInstItem.TBucketArray" und "FInstance", "FLock" und "FBuckets". Das konnte ich in der System.pas verorten. Allerdings auch dort weder Breakpoints gesetzt noch irgendwelche Sonderzeichen. Und nu mit dem Latein am Ende.

Grüße
Cody

[TiGü]

Delphi-Quellcode:

...
{$IFDEF USE_LIBICU}
  LibICUSuffix := '';
{$ENDIF}
{$IFDEF WEAKREF}
  InstHashMap.Finalize;  // <---- Ersten Breakpoint drauf!
{$ENDIF}

{$IF defined(MSWINDOWS) or defined(OSX32)}
  {Uninitialize the default memory manager, and free all memory allocated by
   this memory manager.}
  FinalizeMemoryManager; // <---- Zweiten Breakpoint drauf!
{$ENDIF}
end.

Gehe mal in der System.pas gaaaanz runter bis zum finalization und kloppe mal die Breakpoints wie oben beschreiben rein und beende dein Programm ganz normal.
Wird der erste Breakpoint angesprungen und das CPU-Fenster ist noch nicht offen -> F9.
Geht dann vor dem zweiten Breakpoint das CPU-Fenster auf, dann alles nochmal auf Anfang!

Beim nächsten Beenden bis zum bitteren Erbrechen TInstHashMap.Finalize und die einzelnen TInstBucket.Finalize sowie TInstItem.Free Einträge durchsteppen und mit schlauen Hingucken den Übeltäter identifizieren.
Tritt das Problem immer bei den gleichen Indizes der Schleifen auf?
Immer weiter eingrenzen, irgendwo findest du dann den Übeltäter und kannst die Ursache dingfest machen!


Zusatzfrage: Bei dem Kollegen tritt das auch auf?

[Codehunter]

Das Problem tritt offensichtlich noch vor dem InstHashMap.Finalize auf. Ja sogar noch bevor der finalization-Abschnitt in der System.pas überhaupt begonnen wird.

Irgendwo fand ich auch den Hinweis, dass sowas gerne mal durch vergessene Breakpoints in externen (Microsoft-) DLLs verursacht wird. Da hat doch nicht etwa das Windows-Update irgendwas...???

EDIT: Das letzte das in der System.pas aufgerufen wird bevor das CPU-Fenster aufgeht ist FinalizeUnits EDIT2: Du hast mich da auf eine Spur gebracht. Innerhalb der FinalizeUnits-Prozedur gibt es eine Schleife while Count > 0 do welche reproduzierbar bis Count=506 funktionierte. Ab da krachte es in der darauf folgenden Zeile TProc(P)(); . Diese mit F7 angesprungen versandete im finalization-Abschnitt der SynEdit.pas. Das grenzt die Sache schon etwas ein.

[Codehunter]

So, jetzt bin ich mit viel F7 bis zur wirklich letzten Zeile gekommen, die dann im CPU-Fenster endet:CALL DWORD PTR [EAX] + VMTOFFSET IInterface._Release in der System.pas:_IntfClear-Function. Weiter komme ich mit meinem Latein nun nicht mehr. Demnach soll ein Interface freigegeben werden. Nur welches?

[TiGü]

Kannst du das Argument Dest: IInterface in _IntfClear auf ein TInterfacedObject casten und bei Erforlg dir den TInterfacedObject(Dest).Classtype bzw .Classname ausgeben lassen?

[Codehunter]

Zitat von TiGü:

Kannst du das Argument Dest: IInterface in _IntfClear auf ein TInterfacedObject casten und bei Erforlg dir den TInterfacedObject(Dest).Classtype bzw .Classname ausgeben lassen?

Spannende Frage! So wie die Implementierung von _IntfClear aussieht mit dem Assembler, wüsste ich erstmal nicht wie. Zumal die System.pas an sich ja nicht wirklich editierbar ist.

Via STRG+F7 wird gesagt, TInterfacedObject(Dest) wäre Nil.

EDIT: Dest ist nur zu Beginn der Prozedur Nil. Unmittelbar vor dem IInterface._Release ist sie gesetzt, jedoch nicht zugreifbar (E2171 Auf Variable 'Dest' kann wegen Optimierung nicht zugegriffen werden). Ein {$O-} änderte daran nichts