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.