Access violation in dcc32280.dll während des Kompilierens

[TheFrog]

Wir haben ein relativ umfangreiches Delphi-Projekt mit ca. 20 Runtime-Packages.

Seit der Umstellung auf Delphi 11 Update 1 erhalte ich immer wieder (sporadisch und bis jetzt absolut nicht nachvollziehbar) beim Kompileren der Packages den Fehler:

"Access violation at address 119DA154 in module 'dcc32280.dll'. Read of address 00000030"

Es kommt vor, dass ich mehrere Tage arbeiten kann, ohne auch nur einen Fehler zu erhalten, dann kommt der Fehler wieder sehr gehäuft. Meist hilft dann nur noch, Delphi im Taskmanager abzuschießen.

Mit der eingesetzten Vorgänger-Version von Delphi (10.3 Rio) hatte ich diesen Fehler nie.

Was ich alles schon probiert habe:

• Delphi 11 komplett neu installiert
• "Build all from here"
• "Compile all from here"

Meine Frage:
Hat jemand von euch ähnliche Erfahrungen gemacht? Wenn ja, habt ihr eine Lösung gefunden? Wenn nein, wird's wohl an meinem Projekt liegen :?

Thx schon mal.

[hoika]

Hallo,
könnte an einer Zusatzkomponente liegen.
Hast Du da welche installiert und vielleicht in verschiedenen Versionen?

[TheFrog]

Installiert sind:

MMX code explorer version 15.1.3
GExperts version 1.3.20
RemObjects Hydra

Diese drei Zusätze waren auch schon bei Delphi 10.3 installiert.

[freimatz]

Habe ich seit 24. August mindestens 54 mal. Willkommen im Club. :wall: (es gibt schlimmeres)

[TheFrog]

Was ich noch gefunden habe und heute ausprobiert habe ist folgende Option zu aktivieren:

Project Options --> Building --> Delphi Compiler --> Use MSBuild externally to compile = TRUE

Zumindest heute hatte ich damit keinen internal error mehr. Hat laut Emba wohl was mit zu wenig Arbeitsspeicher zu tun ...

Ich werde es in nächster Zeit mal mit dieser Option beobachten.

[TheFrog]

Update:

Leider erhalte ich den Fehler auch noch, nachdem ich die bereits erwähnte Option "Use MSBuild externally to compile = TRUE" umgestellt habe :wall:

Ist dies ein Speicher-Problem, oder liegt es an meinem Code (wobei Kollegen mit dem absolut gleichen Code kein Problem haben :gruebel:).

Vielleicht hat ja noch jemand eine Idee dazu, ich bin mittlerweile am Verzweifeln.

[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.