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

Delphi-Quellcode:

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

Delphi-Quellcode:

FinalizeUnits

EDIT2: Du hast mich da auf eine Spur gebracht. Innerhalb der FinalizeUnits-Prozedur gibt es eine Schleife

Delphi-Quellcode:

while Count > 0 do

welche reproduzierbar bis Count=506 funktionierte. Ab da krachte es in der darauf folgenden Zeile

Delphi-Quellcode:

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:

Delphi-Quellcode:

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:

Zitat von TiGü (Beitrag 1452172)

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 :(

[hoika]

Hallo,
das hatte ich auch mal.
Kam vom unsauberen Mischen von Interfaces und Objekten.
Dabei wurde das Objekt bereits zerstört, das Interface bekam es aber nicht mit und wollte es noch ml zerstören.
Nun ja, etwas vereinfacht ;)

Lösung war mühselig:
Ausklammern aller Units, laufen lassen
erste Unit rein, laufen lassen

Lösung war dann, unsere Interface-Variablen immer vor dem Verlassen des Scopes explizit auf nil zu setzen.
Vielleicht übergibst Du auch irgendwo ein Interface als Parameter ohne das const.

Du glaubst zu wissen, das es was mit SynEdit zu tun hat.
Kann sein, muss aber nicht.

Viel Erfolg!

[Codehunter]

Zitat:

Zitat von hoika (Beitrag 1452180)

Du glaubst zu wissen, das es was mit SynEdit zu tun hat.
Kann sein, muss aber nicht.

Genau das ist der Punkt. Mehr wie ein Anhaltspunkt ist das nicht, dass er zuletzt im finalization von SynEdit ist. Das Dilemma an der Sache: Ich selbt arbeite in KEINER von meinen Units mit Interfaces. Wenn dann höchstens indirekt mit eingebundenen Komponenten. Weil das Projekt aber laut MMX aus 183 Units (ohne RTL und VCL!) besteht, bin ich da wohl Wochen beschäftigt. :(

[hoika]

Hallo,

Zitat:

Ich selbst arbeite in KEINER von meinen Units mit Interfaces.

Ah so, das ist doof ;(

Sind viele Units in deiner DPR? -> alles raus, dann schrittweise rein
Weißt Du, ab wann das auftrat -> alte Version zurückspielen.

[Codehunter]

Ich werd noch wahnsinnig :evil:

Es sieht so aus als wäre es mein altes Problem mit der Virtualmachine, nur in neuerer Fehlersymptomatik. An den VM-Einstellungen gedreht, weg ist der Fehler.