Debugger hält beim Programmende in CPU-Fenster

[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 von hoika:

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

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.

[MyRealName]

SynEdit hat da ein Problem, weil ich habe an einer Stelle in einer Anwendung SynEdit wegen eines Custom-SQL-Editors im Programm für unsere User. Rufe ich das nicht auf, schließt sich das Programm sauber, öffne ich das Fenster mit dem SynEdit Memo auch nur einmal, dann kriege ich beim Schließen der Anwendung einen Fehler im der was mit einem Interface in SynEdit zu tun hat.

[Codehunter]

Das kann gut sein dass sich da gegenseitig was aufschaukelt. Denn den SynEdit in Verbindung mit dem SQL-Highlighter verwende ich auch.

[Codehunter]

So, wo ich mal wieder Zeit hatte konnte ich das Problem reproduzieren und eingrenzen. Und zwar liegt es am VirtualBox Grafikkartentreiber. Wenn man in den VBox-Einstellungen die Grafikkarte auf VBoxSVGA stellt und den 3D-Support aktiviert, dann wirft SynEdit solche Exceptions. Das kann man mit einem Workaround beheben, indem man in der SynEdit.inc ganz am Ende den DirectWrite-Support auskommentiert:

Delphi-Quellcode:

// DirectWrite
{$IFDEF SYN_DELPHI_XE2_UP}
  //{$DEFINE SYN_DirectWrite}
{$ENDIF}

Dann noch das Synedit-Package neu erzeugen und fertig. Damit habe ich zwar die genaue Ursache noch nicht gefunden, aber zumindest gibts keine Exceptions mehr. Der Nachteil ist, dass Synedit dann wieder GDI zeichnet und entsprechend etwas langsamer ist.