Access violation in dcc32280.dll während des Kompilierens

[himitsu]

Wenn es ein Speicherleck ist, dann sollte es weg sein, wenn extern kompiliert wird, weil jeweils eigener Prozess = eigener Speicher (nicht in IDE) und danach wieder komplett freigegeben.

Ja, da gab es welche, wo Listen/Caches gefüllt werden und erst nach dem letzten Projekt im MultiCompiler wieder freigegeben wurden.
So konnte man z.B. ein bissl tricksen, wenn man die IDE auf 4 GB aufborte, aber seit längerem, hat Emba das nun selber erledigt. (früher hatte die IDE maximal 2 GB RAM zur Verfügung)


Ich hätte gedacht, dass es auch sein könnte, dass Delphi "alle" gewählten Projekte an ein MSBuild übergibt (oder eben je ein MSBuild mit je einem DCC je Projekt)
und dann in sich der Speicher auch füllen könnte,
aber ruft der MSBuild die DCC-Exen auf oder lädt er nur einmal die DCC-DLLs?

Kannst du mal im Taskmanager schauen, ob neben dem MSBuild eine oder mehrere DCC***.exe auftauchen?
Bzw. eine DCC*.exe und die ProzessID ändert sich ständig.

[TheFrog]

Wenn ich mehrere Packages nacheinander kompiliere, dann taucht für jedes Packages, welches extern kompiliert wird, genau eine DCC*.exe im Taskmanager auf mit jeweils einer neuen ProzessID.
Die DCC*.exe wird demnach nach dem Kompiliervorgang des Packages wieder beendet und für's nächste Package eine neue gestartet.