BCB3 - *.exe hat ein Problem festgestellt [doch nicht gelöst]
-
audacia schrieb:
Kolumbus schrieb:
Die fertig compilierte Executable des Projektes lässt sich überall starten, nur auf meinem Rechner nicht... Mal wieder drei Fehlermeldungen, wie immer.
Dabei kannst du noch glücklich sein, daß dein Fall so einfach reproduzierbar ist
Ich hatte ein ähnliches Problem mal mit einem Programm, das sich bei der ersten Ausführung auf einem bestimmten Rechner seltsam verhielt, danach aber einwandfrei funktionierte.Na was ich doch für ein Glückspilz bin
Nicht dass ich schon 3 Monate nach der Ursache suche 
audacia schrieb:
Was hätte ich da nur ohne Virtual PC gemacht...
Liest sich wie ein Wink mit dem Zaunpfahl
audacia schrieb:
Kolumbus schrieb:
Ich habe jetzt eine neue Theorie: Ich habe hier einen Rechner mit Dualkern-Prozessor, kann es daran liegen? Wie könnte ich eingrenzen, ob es daran liegt? ...
Du könntest das Programm auf deinem Rechner mit Prozessor-Affinität starten (z.B. mit einem Tool wie diesem hier).
Leider muss man vor dem Download der Datei die Registrierung abschließen und da steht in den Nutzungsbedingungen:
Delphie-PRAXiS.net schrieb:
Jede Form der Nutzung des Zuganges für gewerbliche Zwecke ist nicht gestattet.
Ich versuche mich generell an soetwas zu halten, daher werd ich mir mal ein anderes Prog suchen. Wenn noch jemand n Link hat, gerne her damit!
Joe_M. schrieb:
Wenn es mit der Prozessorzuweisung zusammenhängt und es sich um einen AMD Prozessor handelt, könnte eventuell auch die Installation des DualCore-Optimizers von AMD helfen.
K, danke - ich behalts im Hinterkopf!
-
Ich habe jetzt mal dieses Tool hier geladen und eine selbst erstellte *.exe für die Nutzung nur eines Kerns eingestellt. Leider hat das keine Veränderung gebracht.
Macht es jetzt trotzdem noch Sinn den Dual-Core-Optimizer zu probieren?
-
Ich fasse es nicht, das Problem ist scheinbar gelöst.
Ich habe allerdings keine (bzw sehr wenig) Ahnung warum. Ich versuche es nochmal zusammenfassend zu beschreiben:
Es dreht sich hier um BCB3-Projekte. Diese wollte ich gerne zu Testzwecken als standalone-exe compilieren und weitergeben bzw. selbst testen. Also habe ich in den BCB3-Projektoptionen immer unter Compiler-Optionen auf "Endgültige Version" gedrückt, unter Linker den Haken bei "Dynamische RTL verwenden" entfernt und unter Packages den Haken bei "Mit Laufzeit-Packages compilieren" entfernt. So lief das Programm jedoch weder im Builder, noch bei mir als standalone-Version.
Aber so ist es doch sogar in den FAQs erklärt???
Nachdem jetzt die explizite Nutzung nur eines Prozessorkernes (mittels Tool) keine Bessserung brachte, habe ich nochmal ein wenig mit den Projektoptionen experimentiert. Da ich insgesamt von den dort einstellbaren Optionen und ihren Auswirkungen keine Ahnung habe, experimentierte ich ausschließlich mit den 3 oben genannten Einstellungen. Folgende Konfiguration funktioniert mit dem derzeitigen Projekt (ich kann es als standalone-exe starten und weitergeben):* Endgültige Version unter Compiler-Optionen drücken
* Dynamische RTL verwenden unter Linker deaktivieren
* Mit Laufzeit-Packages compilieren unter Packages aktivieren(1) Warum ist denn überall beschrieben man soll Laufzeit-Packages für standalone-Progs deaktivieren???
(2) Kann nochmal jemand beschreiben, was die letzten beiden Einstellungen genau bewirken?Auf jeden Fall fände ich es sehr(!) ärgerlich, wenn das alles gewesen sein sollte!
Edit: nur Schönheitskorrektur
Edit2: Noch einen Fehler gefunden und korrigiert
-
Kolumbus schrieb:
(1) Warum ist denn überall beschrieben man soll Laufzeit-Packages für standalone-Progs deaktivieren???
Weil es sonst keine Standalone-Programme sind?
Kolumbus schrieb:
(2) Kann nochmal jemand beschreiben, was die letzten beiden Einstellungen genau bewirken?
Sie beeinflussen, ob du die RTL und die VCL (die Delphi-RTL fällt in letztere Kategorie) dynamisch (als DLLs respektive Packages) oder statisch linkst.
Von welchen DLLs und Packages eine .EXE-Datei abhängt, kannst du, wie ich nicht zu erwähnen müde werde, mit Dependency Walker nachsehen. Wenn du damit deine mit dynamischer RTL und Packages kompilierte .EXE analysierst, solltest du feststellen, daß sie durchaus von zusätzlichen DLLs abhängig ist.
Im Übrigen bezweifle ich, daß du damit die Lösung deines Problems gefunden hast. Das Aktivieren von Packages und der dynamischen RTL bringt mit sich, daß zu Programmstart einige DLLs mehr geladen werden, wodurch sich das Working Set vergrößert, die Speicherverwaltung unterschiedlich strukturiert und der Ablauf während der Ladezeit anders sein kann. Möglicherweise führt das zufällig dazu, daß dein Fehler, ob er nun mit einem Speicherleck, bei dem der Memory-Manager in dieser Konstellation zufällig toleranter ist, mit einem Thread-Synchronisationsfehler oder anderen Widrigkeiten zusammenhängt, zufällig meistens nicht auffällt.
Ich rate dir dringend, das Programm in einem Zustand zu belassen, in dem der Fehler auftritt, und ihn weiter einzugrenzen. Sonst hast du irgendwann vielleicht ein paar Kunden am Hals, auf deren Rechner dein Fehler ganz zufällig andauernd auftritt.
-
K, danke erstmal für die Antworten.
audacia schrieb:
Kolumbus schrieb:
(1) Warum ist denn überall beschrieben man soll Laufzeit-Packages für standalone-Progs deaktivieren???
Weil es sonst keine Standalone-Programme sind?
Klar, leuchtet ein!
audacia schrieb:
Kolumbus schrieb:
(2) Kann nochmal jemand beschreiben, was die letzten beiden Einstellungen genau bewirken?
Sie beeinflussen, ob du die RTL und die VCL (die Delphi-RTL fällt in letztere Kategorie) dynamisch (als DLLs respektive Packages) oder statisch linkst.
Soweit klar, ich dachte da gibts noch Geheimnisse!?
audacia schrieb:
Von welchen DLLs und Packages eine .EXE-Datei abhängt, kannst du, wie ich nicht zu erwähnen müde werde, mit Dependency Walker nachsehen. Wenn du damit deine mit dynamischer RTL und Packages kompilierte .EXE analysierst, solltest du feststellen, daß sie durchaus von zusätzlichen DLLs abhängig ist.
Das glaube ich auch so (aber es ist sicherlich mal interessant zu sehen)! Um so merkwürdiger fand ich ja, dass ich nur die *.exe weitergeben und ohne (sichtbare) Fehler auf einem anderen Rechner ausführen konnte. Aber der PC hatte dann in einem Standardverzeichnis zufällig die richtigen Bibliotheken zur Verfügung nehme ich an!? Oder liefere ich die in der *.exe mit, wenn ich Packages aktiviert habe?
audacia schrieb:
Im Übrigen bezweifle ich, daß du damit die Lösung deines Problems gefunden hast. Das Aktivieren von Packages und der dynamischen RTL bringt mit sich, daß zu Programmstart einige DLLs mehr geladen werden, wodurch sich das Working Set vergrößert, die Speicherverwaltung unterschiedlich strukturiert und der Ablauf während der Ladezeit anders sein kann.
Ich habe nur Packages aktiviert!
audacia schrieb:
Möglicherweise führt das zufällig dazu, daß dein Fehler, ob er nun mit einem Speicherleck, bei dem der Memory-Manager in dieser Konstellation zufällig toleranter ist, mit einem Thread-Synchronisationsfehler oder anderen Widrigkeiten zusammenhängt, zufällig meistens nicht auffällt.
Ich vermute keinen Thread-Synchronisationsfehler. Es gibt im aktuellen Prog einen Thread der im Hintergrund auf Zeichen an einer angegebenen COM-Schnittstelle wartet. Je nach Programmzustand (Nutzereingaben) ist der Thread mal Suspended und mal Resumed. Beim Programmstart wird der Thread mit new als Suspended angelegt, also noch nicht gestartet. Daher kann ich den Thread doch wohl für das "startet-nicht-Problem" ausschließen!? Zu Speicherlecks schreibe ich gleich noch was...
audacia schrieb:
Ich rate dir dringend, das Programm in einem Zustand zu belassen, in dem der Fehler auftritt, und ihn weiter einzugrenzen. Sonst hast du irgendwann vielleicht ein paar Kunden am Hals, auf deren Rechner dein Fehler ganz zufällig andauernd auftritt.
Im aktuellen Problem-Projekt sollte ich "nur schnell" ein paar Captions etc ins Englische übersetzen, das Projekt ist garnicht von mir. Ich kann meine Zeit nicht noch in die Suche nach Fehlern in diesem Projekt zu stecken. Es hat mich nur gewundert, dass genau derselbe Fehler wie bei einem Projekt das ich übernommen habe auftritt!
Das übernommene Projekt von dem ich hier schreibe, ist das Prog, welchem dieser Thread hier zugrunde liegt. Da habe ich aber inzwischen nirgendwo mehr Fehler gefunden. BCB3 compiliert und linkt ohne Warungen und Fehler. Wenn ich das Projekt in einen extra-Ordner kopiere und in BDS2006 lade, compiliert und linkt BDS2006 auch ohne Warnungen und Fehler. Selbst Codeguard beschwert sich über nichts, wenn aktiviert!? Also kann ich doch davon ausgehen, dass sich keine Speicherlecks versteckt haben!? Trotzdem lässt sich auch dort ohne Packages keine ausführbare *.exe erstellen.
Das Ganze nervt ziemlich! Ich habe jetzt nochmal Testweise ein neues Projekt erstellt, nur ne Form mitnem Button drauf - da funktioniert es ohne Probleme, also wie überall beschrieben - "Mit Laufzeit-Packages compilieren" deaktiviert.Faszit: Ich lasse das Übersetzungsprojekt wie es ist und mein übernommenes Projekt schreibe ich nochmal von Grund auf neu!
Wie immer bin ich dankbar für weitere Anmerkungen!
-
Selbst Codeguard beschwert sich über nichts, wenn aktiviert!? Also kann ich doch davon ausgehen, dass sich keine Speicherlecks versteckt haben!?
Den Codeguard interessieren keine Speicherlecks.
-
murks schrieb:
Den Codeguard interessieren keine Speicherlecks.
Diese Aussaga ist schlicht und ergreifend falsch.
-
Joe_M. schrieb:
murks schrieb:
Den Codeguard interessieren keine Speicherlecks.
Diese Aussaga ist schlicht und ergreifend falsch.
Nein. Der Codeguard beim BCB ist schlichtweg bekanntermassen fehlerhaft implementiert. Er lässt sich in dieser Hinsicht sehr "einfach austricksen".
-
Kolumbus schrieb:
audacia schrieb:
Im Übrigen bezweifle ich, daß du damit die Lösung deines Problems gefunden hast. Das Aktivieren von Packages und der dynamischen RTL bringt mit sich, daß zu Programmstart einige DLLs mehr geladen werden, wodurch sich das Working Set vergrößert, die Speicherverwaltung unterschiedlich strukturiert und der Ablauf während der Ladezeit anders sein kann.
Ich habe nur Packages aktiviert!
Da hätte ein inklusives oder stehen sollen
murks schrieb:
Den Codeguard interessieren keine Speicherlecks.
Doch.
murks schrieb:
Der Codeguard beim BCB ist schlichtweg bekanntermassen fehlerhaft implementiert. Er lässt sich in dieser Hinsicht sehr "einfach austricksen".
Beispiel bitte.
Außerdem heißt das noch lange nicht, daß CodeGuard deshalb unbrauchbar wäre. Die meisten Speicherlecks und Zugriffsverletzungen findet es trotzdem.
-
audacia schrieb:
murks schrieb:
Der Codeguard beim BCB ist schlichtweg bekanntermassen fehlerhaft implementiert. Er lässt sich in dieser Hinsicht sehr "einfach austricksen".
Beispiel bitte.
Oh ja, das wäre mal interessant!
-
Ich hatte kürzlich nen seltsamen Effekt mit vector. Offenbar passierte eine Zugriffsverletzung (Exception etc.), aber CodeGuard hat sie nicht bemerkt. Minimalquellcode dazu kann ich leider nicht liefern, der Fehler trat so nur im Kontext des Projekts auf. Bin dann beim Debuggen drauf gestoßen, dass der vector zu klein war. CodeGuard ist also kein Allheilmittel, obwohl in vielen Fällen hilfreich.