Fehlermeldung in RadStudio XE2



  • Hallo zusammen,

    ich hab vor einiger Zeit auf Radstudio XE2 gewechselt. Seit dem hab ich nur Probleme und ich hab keine Ahnung wo die her kommen.

    Meine Projekte kann ich 5-10 mal Compilieren dann kommt irgendwann die Fehlermeldung:

    [BCC32 Fataler Fehler] F1014 SAVEmem konnte nicht zugewiesen werden
    

    bei allen weiteren Compilierungen kommt dann:

    [BCC32 Fehler] "bcc32" exited with code 1.
    

    Daraufhin brauch ich nur Das Studio zu schließen, neu zu öffnen und ich kann wieder alles wieder Problemlos Compilieren, zumindestens ein paar mal.

    Das ist echt nervig. Neuinstallation hilft auch nicht. Ich hab aber auch recht wenig zu dem Fehler gefunden.

    Hat jemand eine Idee was ich dagegen machen kann oder hilft nur XE2 in den Mülleimer zu befördern? Bugfixes wird es ja eh nicht geben...



  • JBOpael schrieb:

    Hat jemand eine Idee was ich dagegen machen kann

    "Projektoptionen|Projekteigenschaften|C++-Compiler in separatem Prozeß starten"



  • Auch wenn es nicht ganz zum Thema passt, hänge ich mich da einfach einmal dran.

    Mich überkommen auch immer wieder Zweifel ob es richtig war sich die XE2 zuzulegen. Mit dem RAD Studio 2007 hatte ich viele ungereimtheiten und Fehler nicht die ich mit dem XE2 habe. Ich habe auch schon mit dem Gedanken gespielt, wenn möglich das XE2 zurückzugeben oder Verkaufen zu können und mit dem 2007er weiterzumachen, oder vielleicht ganz auf OpenSource (wxWidgets) umzusteigen.



  • Netzschleicher schrieb:

    Mich überkommen auch immer wieder Zweifel ob es richtig war sich die XE2 zuzulegen. Mit dem RAD Studio 2007 hatte ich viele ungereimtheiten und Fehler nicht die ich mit dem XE2 habe. Ich habe auch schon mit dem Gedanken gespielt, wenn möglich das XE2 zurückzugeben oder Verkaufen zu können und mit dem 2007er weiterzumachen, oder vielleicht ganz auf OpenSource (wxWidgets) umzusteigen.

    Ich glaube, wir hatten das Thema schon mal. Nach meiner Erfahrung ist C++Builder XE die stabilste Version und hat außerdem alle Features, die (mir) wichtig sind. In den nachfolgenden Versionen driftet die Entwicklung vollends ab in Bereiche, die mir nichts bringen (FireMonkey, Live-Binding, DataSnap), das Kernfeature VCL wird vernachlässigt, IDE- und Compilerprobleme akkumulieren sich, und es gibt bis dato keine Bestrebungen, die Probleme anzugehen (XE3 ist kein Stück besser). In der Zukunft soll der Großteil der Ressourcen wohl in die Entwicklung für mobile Geräte (iOS und Android, aber nicht Windows RT) mit FireMonkey gehen, was mich und wohl die Mehrheit der VCL-Benutzer überhaupt nicht tangiert.

    Nach einem brauchbaren Nachfolger für die VCL suche ich auch schon länger vergeblich. Wenn ein natives GUI und sparsamer Umgang mit Ressourcen nicht so wichtig sind, kann man WPF nehmen; und in kleineren Projekten, für die man nicht irgendwelche Spezialkomponenten wie Grids, Treeviews, Texteditor-Controls, Spreadsheets oder Charts und Plots benötigt, mögen wxWidgets oder WTL ausreichen. Aber so eine richtige Alternative zur VCL mit ihrem Komponentenmarkt sehe ich eigentlich nicht 😞



  • audacia schrieb:

    Ich glaube, wir hatten das Thema schon mal.

    Ja, wir hatten das in einem anderen Tread schon einmal diskutiert.

    audacia schrieb:

    Nach einem brauchbaren Nachfolger für die VCL suche ich auch schon länger vergeblich. Wenn ein natives GUI und sparsamer Umgang mit Ressourcen nicht so wichtig sind, kann man WPF nehmen; und in kleineren Projekten, für die man nicht irgendwelche Spezialkomponenten wie Grids, Treeviews, Texteditor-Controls, Spreadsheets oder Charts und Plots benötigt, mögen wxWidgets oder WTL ausreichen. Aber so eine richtige Alternative zur VCL mit ihrem Komponentenmarkt sehe ich eigentlich nicht 😞

    Und da muß ich Dir zustimmen. An sich gefällt mit die IDE der Borland/CodeGear/Embarcadero Linie recht gut. Bis auf die Kleinigkeiten die verschlimmbessert wurden. Und mit dem Komponentenumfang der VCL insbesondere wenn ich noch die JEDI Jvcl miteinbeziehe können z.B. die wxWidgets nicht mithalten. Obwohl die einen gewissen Charme haben beim Programmieren mit diesen.

    Ist wirklich sehr schade das ganze.



  • Netzschleicher schrieb:

    Ist wirklich sehr schade das ganze.

    Der Produkt-Manager schreibt gerade in seinem Blog

    Yes, it’s a great time to be a consumer and a developer. And a good time brush up on your C++.

    Hoffen wir einfach mal, dass der letzte Satz ein Selbstgespräch war. 😃



  • nn schrieb:

    Hoffen wir einfach mal, dass der letzte Satz ein Selbstgespräch war. 😃

    Der ganze Blog ist doch ein Selbstgespräch wenn man keine Kommentare zulässt 🙂



  • JBOpael schrieb:

    Hat jemand eine Idee was ich dagegen machen kann

    "Projektoptionen|Projekteigenschaften|C++-Compiler in separatem Prozeß starten"

    eine Alternative ist das nicht wirklich. Das Compilieren dauert dann ja gefühlte 10 mal so lange... 😞
    noch andere Ideen?



  • ich denk ich habe das Problem jetzt gelöst. Naja, gelöst ist vielleicht etwas übetrieben, aber ich hab jetzt alles nochmal Platt geamcht und diesmal Win 7 64 Bit installiert. Seitdem läuft XE2 bislang ohne Probleme. XE2 scheint also irgendwie die Windows 32Bit Version nicht zu mögen.



  • Unter 64-Bit-Systemen kann auch 32-Bit-Prozessen mehr Speicher als den 2GB, maximal 3GB, unter einem 32-Bit-System zugewiesen werden; also ist die Lage vielleicht dadurch etwas entspannter.



  • Thread mal wieder ausgrab:
    Da ich das Problem ebenso noch bis XE8 mit herumschleppte, habe ich mir auf Empfehlung Twine Compile heruntergeladen und installiert. Seitdem geht das Compilieren wesentlich flotter und die Savemem Probleme gehören nun der Vergangenheit an.

    Hier zu finden: http://www.jomitech.com/twine.php

    Ist leider nicht kostenlos, man kann es aber 30 Tage lang kostenlos testen. Auf jeden Fall hat mich dieses Plugin sofort so überzeugt, das ich mir gleich eine Lizenz gekauft habe.

    Schade schade nur, das Embarcadero das selbst nicht so hinbekommen hat.



  • Das Problem kenne ich auch XE6 (eventuell auch noch Seattle).
    Was ich jedoch herausgefunden habe, daß in den meisten Fällen wenn ich den Fehler habe Windows im Hintergrund irgendwelche Updates installiert hat.
    Dies wird beim herunterfahren bzw. neu starten durch die typische Windows wird konfiguriert Meldung sichtbar.
    Wenn ich den Fehler habe gehe ich wie folgt vor:
    1. Komplett neu kompilieren
    2. IDE neu starten
    3. PC neu starten

    Spätestens nach Schritt 3 funktioniert wieder alles.
    Ist nervig, aber man hat sich mittlerweile so einige Workarounds angewöhnt.

    MfG Stephan



  • Stephan schrieb:

    ...
    Ist nervig, aber man hat sich mittlerweile so einige Workarounds angewöhnt.

    MfG Stephan

    Das hatte ich auch alles vorher gemacht, aber in letzter Zeit half auch das nix mehr. Ich habe auch die option "--savemem=value" benutzt, da kam dann meist der Fehler, das mehr als 78MB nicht allokierbar sind. Und das bei 12GB Hauptspeicher. 😕 😕

    Ab Seattle kann der Compiler 4GB Speicher nutzen, da hatte ich diese Probleme bisher noch nicht. Twin Compile hat sich dort auch als Plugin eingetragen.


Anmelden zum Antworten