XE3-Compiler-Speicherleck

[himitsu]

Kennt sich zufällig jemand im Delphi aus und kann bei der Suche helfen?

Wie in http://www.delphipraxis.net/170973-a...bstuerzen.html aufgefallen ist, besitzt der Compiler ein nettes Speicherleck, welches Delphi recht schnell komplett verrecken läßt.

Beim Kompilieren steigt der Speicher gnadenlos an und bei knapp 1,3 GB (laut Taskmanager) kommt dann ein OutOfMemory und ab da kann man mit Delphi praktisch nicht mehr arbeiten.
Wenn das AQ-Time-Package noch im Delphi registriert ist, dann reagiert Delphi mehrere Minuten garnicht mehr und stützt schlußendlich ab.

Ich hab jetzt erstmal nur einen kurzen Test gemacht und Speicher gesucht, welcher neu reserviert wurde (über VirtualAlloc bei Windows).
In den beiden Dateien wurde alles gelöscht, was kurz vor dem Kompilieren bereits reserviert war. Dieses befindet sich in den Dateien/Speicherabbildern und der Rest wurde mit 0 gefüllt.

Was komisch ist, daß sich der größte Teil wieder verflüchtigt (bis auf 100-200 MB), wenn man Datei > Alle Schließen ausführt :gruebel:, was also bedeuten würde, daß der Speicher entweder an den Projekten oder an der Projektgruppe hängt.

Ein kleiner Teil des zusätzlichen Speichers kommt eventuell von den DDevExtensions (das einzige Plugin, welches aktuell in meinem XE3 rumgammelt),
aber auch ohne die DDevExtensions zeigt sich dieses Problem noch, womit es nicht am Andreas liegt.

Ach ja, mein Testprojekt ist eine Projektgruppe aus allen Projekten/Packages/Demos des PHP4Delphi, welche ich kompilieren lasse.
> 3 kleine BPLs, davon ein Laufzeitpackage (es ist aber egal, ob dieses installiert ist, oder nicht)
> 26 winzige DLLs und 21 knuffige EXEen

http://fnse.de/DL/Debug.7z (130 MB)
Project3.exe.mem3_1 - enthält die zusätzlichen 602 MB kurz nach dem Kompilieren
Project3.exe.mem3_2 - enthält die zusätzlichen 349 MB nachdem alle Dateien geschlossen wurden.



(kleinere) Speicherlecks im Command-Line-Compiler sind ja relativ unproblematisch, da Dieser eh nicht lange lebt, aber wenn sowas die IDE mehrmals am Abend vis zum Rand vollmüllt, dann macht das keinen Spaß.
Und ich kann auch nicht alle 5 Minuten in den Taskamanger gucken, um notfalls rechtzeitig den Speicher zu leeren und alles neu zu laden, bevor es abstürzt und ich nicht mehr speichern kann.

Die kompletten Speicherabbilder komprimieren grade ... also falls jemand mehr braucht.

[PeterPanino]

Ist zwar nur ein Workaround, aber mir hat der System Explorer bei anderen Programmen mit Speicherlecks sehr geholfen. Der hat eine Option (Menu -> Options -> Processes), die automatisch in einstellbaren Zeitabständen den Speicher aufräumt. Seitdem ich das verwende, läuft mein System stabiler.

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1188091)

Was komisch ist, daß sich der größte Teil wieder verflüchtigt (bis auf 100-200 MB), wenn man Datei > Alle Schließen ausführt :gruebel:, was also bedeuten würde, daß der Speicher entweder an den Projekten oder an der Projektgruppe hängt.

Der Compiler hat einen eigenen Speichermanager (nicht FastMM), der beim Schließen des Projekts den Befehl bekommt, sämtlichen nicht (mehr) verwendeten Speicher freizugeben. (Das passiert erst seit XE).
Der Compiler hält so ziemlich alle DCU-Daten, die er einmal gelesen hat im Speicher (Unit-Cache) und ersetzt sie nur, wenn eine Unit verändert und neukompiliert wird. Der dabei ggf. freigegebene Speicher landet wieder im Compiler-Speichermanager, der ihn nicht an Windows zurückgibt, womit der IDE Speichermanager nicht an den Speicher herankommt.
Wenn natürlich im Compiler ein Speicherleck ist, kann der Compiler-Speichermanager auch auf Befehl hin den Speicherblock nicht freigeben, da er ja angeblich genutzt wird.

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1188156)

Das passiert erst seit XE

Aso. Also das letzte große Speicherleck wr mir im TDE aufgefallen und da blieb es natürlich erhalten.


Hmmm, aber daß da knapp 1 GB in der Cache anfällt, für die paar Units, kann ich erstmal nicht glauben und selbst wenn, dann wäre es doch praktisch, wenn er sich etwas entleert, sobald der RAM fast am Überlaufen ist.
Das sind insgesammt 70 DCUs mit zusammen 1,99 MB auf der Platte und raus kommen dabei 47 EXE/DLL/BPLs mit zusammen 84,6 MB (als Debug-Build) und der Speicherverbrauch geht beim Build-All (laut Taskmnager) von knapp 80-250 MB auf mindestens 1,3 GB hoch.

Nja, eventuell können sie ja wenigstens erstmal die 3 GB-Option für die IDE aktivieren?
Dann würde der Speicher etwas länger ausreichen. :angle2: (solange bis die IDE auch irgendwann mal 64 Bit kann)

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1188175)

Hmmm, aber daß da knapp 1 GB in der Cache anfällt, für die paar Units, kann ich erstmal nicht glauben

Der Compiler speichert da schon noch ein paar mehr Daten ab. Zudem braucht er für seine Arbeit auch etwas Speicher. Wenn du genaueres wissen willst, müsstest du Embarcadero fragen, wobei ich bezweifle, dass die dazu Aufkunft geben können (im Sinne von sofort wissen was der Compiler macht).

Zitat:

dann wäre es doch praktisch, wenn er sich etwas entleert, sobald der RAM fast am Überlaufen ist.

Der Compiler-Speichermanager weiß nichts davon, dass er sich den Adressraum mit dem IDE Speichermanager teilt. Zudem ist der Compiler mehr für den Kommandozeilen-Compiler ausgelegt und wurde nur für Delphi in eine DLL umgebaut: Intern tickt der selbe Speichermanager und der selbe Code in der dccXXX.dll wie in der dcc32.exe.

Zitat:

Nja, eventuell können sie ja wenigstens erstmal die 3 GB-Option für die IDE aktivieren?

Dank des Kopierschutzes kann man das ja nicht selbst so leicht machen (=> einfach das Linker-Flag setzen). Es gibt aber Wege und Mittel das trotzdem hinzubekommen. Dann jedoch scheitert man an den vielen Bereichsüberschreitungen die nicht abgefangen werden (da Release-Build) zu späteren Zugriffsverletzungen führen. Fazit: Die IDE ist nicht 3GB fähig (die Komponenten und IDE Plugins mal außen vorgelassen).



Kannst du diese groupproj Datei für PHP4Delphi anhängen? Es handelt sich schon um http://users.telenet.be/ws36637/php4delphi.html oder?

[Memnarch]

Zitat:

Zitat von himitsu (Beitrag 1188175)

Hmmm, aber daß da knapp 1 GB in der Cache anfällt, für die paar Units, kann ich erstmal nicht glauben

Mh habe ich das richtig gelsen, dass du mehrere megabyte kompiliert hast? Bin bei der aufzählung etwas verwirrt.

Nicht das ich mich jetzt im Delphi Compiler auskenne, aber etwas dass der GCC und mein Compiler machen, ist die geparsten Daten in einen AST(ABstract Syntax Tree) zu packen(wobei mein AST vllt nicht so abstrakt ist *hust*). Das bläht natürlich auf, ist aber soweit ich gelsesen habe ein gängiger schritt bei Compilern, und es könnte gut sein, dass Delphi das auch macht.

Und der AST ist dan nur ein Teil des ganzen. die DCUs die du siehst, sind lediglich "fertiger" (bereits optimierter?) bytecode, und damit recht schlank.

[himitsu]

Im Prinzip ist das doch noch ein recht kleines Projektchen und ich komm jetzt schon an die Grenzen der IDE ... was soll denn passieren, wenn man da mal richtig an die Arbeit geht?

Zitat:

Zitat von Memnarch (Beitrag 1188211)

Mh habe ich das richtig gelsen, dass du mehrere megabyte kompiliert hast? Bin bei der aufzählung etwas verwirrt.

Kommt drauf an, von welcher Seite man das betrachtet.
Auf Seite der Quellcodes sind's nur ein paar Kilobyte

178 Quelldateien (PAS/DFM/DPR/DPK) = 2,2 MB
=
70 DCUs = 1,99 MB (inkl. Debuginfos)
47 EXE/DLL/BPLs = 84,6 MB (als Debug-Build)
1,2 GB welche in der IDE beim Kompilieren entstehen

340.000 Zeilen als Build All = 1,3 GB RAM
36.700 Zeilen als Compile All = 1,3 GB RAM (konnte ich bis vor wenige Minuten nicht machen, da es mehrere gleichnamige Units gab)
Mehrfaches Kompilieren einer Unit macht verursacht wenigstens nicht gleich mehr Speicher.


@jbg:
Jupp.
http://FNSE.de/DL/PHP4Delphi%208.0%202012-10-21%20[himitsu].7z (noch nicht fertig)
Versuche ein paar Fehler rauszumachen, welche bei der Umstellung auf Unicode eingebaut wurden und nebenbei alle APIs überarbeiten/prüfen, damit es auch mal mit 64 Bit zurechtkommt.

[himitsu]

Krass, es gibt sogar eine eigene Ecke nur für Speicherlecks. :stupid:
http://qc.embarcadero.com/wc/qcmain.aspx?da=5116

http://qc.embarcadero.com/wc/qcmain.aspx?d=81427

[jbg]

Ich habe mal schnell ein kleines IDE Plugin geschrieben, dass den Speicherverbrauch des Compilers auflistet.

Installation:
Unter
[HKCU\Software\Embarcadero\BDS\10.0\Experts]
den Eintrag
"DccMemAnalyzer_Debug"="C:\Somewhere\On\My\Disk\Dc cMemAnalyzer.dll"
eintragen und die IDE starten.
Danach sollte schon während des Splashscreens ein Fenster mit einem Memo aufgehen. Der Button "Refresh" füllt das Memo mit den aktuellen Speichermanager Daten des Compilers.

Nach dem Kompilieren sieht man, dass über 700 MB an Units geladen sind. Für jedes kompiliertes Projekt wird der gesamte Unit-Betand (System.dcu, SysUtils, Classes.dcu, ...) gehalten, was das ganze so dermaßen aufbläst.

[himitsu]

Zitat:

Für jedes kompiliertes Projekt wird der gesamte Unit-Betand

Toll, grade die Units, welche den größten Teil an den meinen/diesen Projekten ausmachen.
Das heißt also, wenn die es irgendwann mal lernen Resourcen mehrfach zu nutzen, daß ich doch keine 64-Bit-IDE benötige. :angle2:




Ich hatte es vorhin, alleine mit dem Bearbeiten vieler Units, geschafft, die IDE abstürzen zu lassen.

War auch noch so im Tippen vertieft, daß ich nicht alle 2 Sekunden gespeichert hatte. :oops:
Fazit: Ausreichend Arbeit war umsonst. Danke Emba.

Ich vermute mal, daß hier das Code Insight dran Schuld war, welches ständig im Hintergrund rumkompiliert.


Hab mir jetzt erstmal 'nen billigen Wächter erstellt, der mich jetzt wenigstens etwas vorwarnt. :-D

Du sagtest doch vorhin was davon, daß der Speichermanager des Compileres eine Aufräumfunktion hat.
Könnte man diese irgendwie aufrufen? (ohne daß es danach knallt)


Bezüglich dem "seit XE ist der Compiler/Compilierspeicher an Projekte gebunden", das erklärt auch noch ein anderes Phänomen, welches mich schon etwas genervt hat.

Früher konnte man schnell mal eine billige Unit erstellen oder öffnen, ohne daß sie zu einem geladenem Projekt gehört und hatte darin dennoch Funktionen, wie Code Insight und Dergleichen, zur Verfügung.
Das funktioniert jetzt leider auch nicht mehr.

[Nersgatt]

Zitat:

Zitat von jbg (Beitrag 1188424)

Ich habe mal schnell ein kleines IDE Plugin geschrieben, dass den Speicherverbrauch des Compilers auflistet.

Würden Dir die Ausgaben des Plugins denn bei irgendetwas helfen, dort Besserung zu schaffen? Dann würde Dir das zumailen. Es ist jetzt 7:54, ich arbeite seit 7:30 Uhr. Und genau jetzt werde ich das erste für den heutigen Tag die IDE neu starten, weil sie "Zu wenig Arbeitsspeicher" anmeckert...

[jbg]

Zitat:

Zitat von Nersgatt (Beitrag 1188440)

Würden Dir die Ausgaben des Plugins denn bei irgendetwas helfen

Nicht wirklich. Denn nur wenn die "FreeList" groß wäre, könnte ich was einbauen, das deren Speicher an Windows zurück gibt. Ansonsten kann ich nur die Units entladen (sofern ich dahinter komme wie das geht) aber dann dürfte der Debugger so seine Probleme bekommen. Die Units "sharen" ist nicht wirklich möglich, da dazu der Compiler erheblich verändert werden müsste (Referenzzählung). Das ich das von außen über ein Plugin machen kann ist eher unwahrscheinlich, allein schon daher, dass ich nicht weiß wo überall das eingebaut werden müsste und ich nur noch mit Assembler-Code-Patches hantieren müsste.


UPDATE:
Hab da doch noch eine Idee. Der generierte Code, der in den DCU Dateien liegt sollte sich möglicherweise zusammenfassen lassen. Ich müsste mich also beim Laden der DCU einklinken und die Daten in einen anderen "Unit-Share" Speicherbereich auslagern und beim Freigeben diesen der Unit diesen auch freigeben. Dadurch würden nur noch die Symbole, Typen, Prozedure-Definitionen Platz weg nehmen. Wieviel sich da einsparen lässt muss ich aber vorher noch herausfinden, nicht das ich mir die Arbeit für ein paar Bytes mache.

[Delphi-Laie]

Ist der Fehler (Embarcadero) schon bekannt? Falls nein, könnte das mal bitte jemand dort veröffentlichen? Oder wengistens Herrn Eissing darob informieren?

[Memnarch]

Zitat:

Zitat von jbg (Beitrag 1188463)

da dazu der Compiler erheblich verändert werden müsste (Referenzzählung).

Mh, Wie kommst du den da auf referenzzählung?

[himitsu]

@Delphi-Laie: Jupp, denen isses bekannt.

Zitat:

Zitat von himitsu (Beitrag 1188329)

Krass, es gibt sogar eine eigene Ecke nur für Speicherlecks. :stupid:
http://qc.embarcadero.com/wc/qcmain.aspx?da=5116

http://qc.embarcadero.com/wc/qcmain.aspx?d=81427

@Memnarch: Wenn mehrere Projekte (bzw. deren jeweils eidene Compiler-Instanzen) untereinander die selben Units sharen, dann müßte man wohl irgendwie mitzählen, damit es wieder freigegeben werden kann, wenn es keiner mehr braucht. :wink:

@jbg: Eventuell kannst man auch nur einfach das provuzieren, wie denn man ein Projekt schließt und es wieder öffnet ... also einfach nur den ganzen Cache leeren und auf Anfang zurücksetzen. (falls das einfacher ist)

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1188530)

also einfach nur den ganzen Cache leeren und auf Anfang zurücksetzen. (falls das einfacher ist)

Der Debugger und CodeInsight benötigen ja die Units. Wenn ich es hinbekomme, dass die Units den meisten Speicher teilen, dann dürfte es nicht mehr ganz so extrem Wachsen.

[himitsu]

Wenn Emba den meisten Cachespeicher in MMFs (mit 'ner Tempdatei verknüpft) legen würde, dann könnte selbst die 32 Bit IDE wesentlich mehr Speicher im RAM haben, als nur poplige 32 Bit.
(mit Datei kann man mehr Speicher verschwenden, und müllt die PageFile nicht voll)

Bei Speichermangel (für Windows) wird es in die Datei geschrieben und ansonsten würde die Windows das Wichtigste die meiste Zeit im RAM cachen.

[jbg]

Das ist leider kein Cache im Sinne eines Caches. Die DCU Datei wird eingelesen und dann alle Referenzen, die in der DCU als Index liegen in Pointer umgewandelt. Danach wird während des Kompilierens/Linkes Änderungen an den geladenen Symbolen gemacht (insbesondere Flags). Es fehlt einfach die Trennung zwischen statischen Daten und Arbeitsdaten. Somit kann man nichts zusammen fassen und mit MMFs kann man sich auch nicht behelfen, da schon allein beim Laden der DCUs Änderungen notwendig sind (=> Referenzen auflösen).



Das mit dem generieren Code Zusammenfassen bringt nicht viel. Bei dem Demoprojekt kommen da gesamt gerade einmal 77 MB zusammen. Wenn da doppelte zusammengefasst werden wird es wahrscheinlich auf unter 20 MB fallen, aber das sind Peanuts im Vergleich zu den anderen 600 MB.

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1188556)

Das mit dem generieren Code Zusammenfassen bringt nicht viel.

:cry:

Nja, zumindestens ist mir nun die IDE nicht mehr unter den Fingern wegverreckt. (werde jetzt ja gewarnt :) )

[jbg]

Ich habe jetzt mal deine Idee mit dem "Aufräumen der Units" in den DCC Memory Analyzer eingebaut. Mit der CheckBox kannst du das "Feature" (de)aktivieren um einen Vergleich zu haben.

Wenn die Checkbox gesetzt ist, werden vor dem Kompilieren eines Projekts sämtlichen Units aller anderen Projekte (in allen Platformen) freigegeben.

Ich kann nicht garantieren, dass die IDE bzw. der Compiler sich dabei normal verhalten. Interessant wäre es, wie sich CodeInsight, ErrorInsight, HelpInsight, der Debugger und der Compiler sich verhalten. Funktioniert das Debuggen in ein "anderes (DLL/BPL) Projekt" noch, sieht man die Symbole, ...

Viel Spaß beim Testen.

[himitsu]

Der RAM läuft nimmer über und das Code-Insight scheint bisher problemlos zu funktionieren.

Einmal (von 3-4 Durchgängen), ist der Compilier mittendrin abgebrochen "Es ist ein Fehler aufgetreten" und sonst wurde nichts gesagt, aber IDE und Compiler lief danach ohne Probleme weiter.

Im Prinzip könntest du ja vorher den Speicher prüfen und nur alles freigeben, wenn z.B. keine 500 MB mehr frei sind, damit würdest du nicht so häufig eingreifen.

[Kidi]

Hallo alle zusammen,
ich habe die Dll ins Delphi Bin Verzeichnis kopiert.
Nun startet Delphi nimmer, sondern verweist auf eine Interneseite von Embarcadero mit der Fehlermeldung "Product or License Validation Error".
Liegt der Fehler an der Dll oder muß diese in ein anderes Verzeichnis?

Grüße
Dietmar

[USchuster]

Zitat:

Zitat von Kidi (Beitrag 1190269)

Hallo alle zusammen,
ich habe die Dll ins Delphi Bin Verzeichnis kopiert.
Nun startet Delphi nimmer, sondern verweist auf eine Interneseite von Embarcadero mit der Fehlermeldung "Product or License Validation Error".
Liegt der Fehler an der Dll oder muß diese in ein anderes Verzeichnis?

Das ist ganz normal - also die DLL muss in ein anderes Verzeichnis. Das ist XE3 wo jede DLL in $(BDSBIN) signiert sein muss. Das man Dateien neu signieren kann hat EMBT wohl niemand gesagt.

[sh17]

Gibts da was neues oder ist das im aktuellen Update von XE3 behoben? Ich bekomm nicht mal meine Projektgruppe mit schon ein paar Projekten durchkompiliert ohne die 1.x GB zu durchbrechen.

[mulltonne]

@jbg

Danke für deine dll mit der funktioniert es super. Hab zu diesem Thema ein Servicevorgang bei embarcadero.
Kannst du eventuell die Sourcen für die dll hier zu verfügung stellen damit ich das den Mitarbeitern von embarcadero zeigen kann.

Zudem würde mich interessieren wie der fix funktioniert

Danke im voraus

[TiGü]

Ich hole den Thread mal hoch!

Könnt ihr ähnliches Verhalten in XE4 beobachten?