BCB3 - *.exe hat ein Problem festgestellt [doch nicht gelöst]

Kolumbus

Ich habe das Projekt jetzt einfach mal in BCB6 geöffnet und Alles neu erstellen lassen. Dabei wurde noch ein Fehler gefunden. Diesen habe ich korrigiert und dann das Projekt nochmal erstellt. Jetzt funktioniert das Programm, wenn ich die Executable starte. Öffne ich das Projekt nun wieder in BCB3, erstelle das Projektziel neu und starte die Executable, bekomme ich wieder eine Fehlermeldung und das Prog startet nicht.
Sollte ich jetzt trotzdem mit dem CodeGuard nachschauen oder liegt das Problem wahrscheinlich woanders?

Th

Ja, laß es mal mit CodeGuard überprüfen. Vielleicht ist ja wirklich noch ein Fehler, der sich nur in der Release-Version vom BCB3 zeigt.
Evtl. findet CodeGuard trotzdem den Fehler auch bei der BCB6-Version deines Projekts.

Ansonsten müßtest du halt den Fehler mit Log-Dateien oder MessageBoxen eingrenzen...

Kolumbus

Morris Szyslak schrieb:

... Im BCB6 gibt es in Projektoptionen ein Tab "CodeGuard". ...

Leider nicht! In den Projektoptionen (Projekt->Optionen) gibt es bei mir überhaupt keine Tabs
Kann es sein, dass es BCB6 etwas Anderes ist als BDS2006?

Edit: Ok, SRY, habs gefunden. Wird direkt in Tools->CodeGuard-Konfiguration aktiviert!

Kolumbus

Ok, so sieht die ProjectX.cgl aus:

CodeGuard schrieb:

Fehler 00119. 0x310000 (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00120. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00121. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00122. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00123. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00124. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00125. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00126. 0x310000 (r) (Thread 0x0EF0):
Falscher Parameter: Falsches Datei- oder Pipe-Stream (0x327AEC5C) wurde an die
Funktion weitergegeben.
fgetc(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 23:
| { // get a char element from a C stream
| int _Meta;
|> if ((_Meta = fgetc(_File)) == EOF)
| return (false);
| else
Aufrufhierarchie:
0x0040DF1E(=ProjectX.exe:0x01:00CF1E) c:\programme\borland\bds\4.0\include\dinkumware\fstream#23
0x0040CC4F(=ProjectX.exe:0x01:00BC4F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#366
0x0040C1C3(=ProjectX.exe:0x01:00B1C3) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#437
0x004068FD(=ProjectX.exe:0x01:0058FD) c:\programme\borland\bds\4.0\include\dinkumware\streambuf#109
0x00404942(=ProjectX.exe:0x01:003942) c:\programme\borland\bds\4.0\include\dinkumware\istream#658
0x00403B39(=ProjectX.exe:0x01:002B39) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#78

------------------------------------------
Fehler 00127. 0x310000 (Thread 0x0EF0):
Falscher Parameter: Falsches Datei-Stream (0x327AEC5C) wurde an die Funktion
weitergegeben.
fclose(0x327AEC5C)

| c:\programme\borland\bds\4.0\include\dinkumware\fstream Zeile 203:
| if (!_Endwrite())
| _Ans = 0;
|> if (fclose(_Myfile) != 0)
| _Ans = 0;
| }
Aufrufhierarchie:
0x00406B3F(=ProjectX.exe:0x01:005B3F) c:\programme\borland\bds\4.0\include\dinkumware\fstream#203
0x00404A69(=ProjectX.exe:0x01:003A69) c:\programme\borland\bds\4.0\include\dinkumware\fstream#716
0x00403B48(=ProjectX.exe:0x01:002B48) C:\ProjectX\C++ Arbeitsordner\SRC\Unit2.cpp#79
0x5205010F(=vcl100.bpl:0x01:06F10F)
0x5204FD52(=vcl100.bpl:0x01:06ED52)
0x00401FF8(=ProjectX.exe:0x01:000FF8) c:\programme\borland\bds\4.0\include\vcl\Forms.hpp#1008

------------------------------------------
Fehler 00149. 0x300010 (Thread 0x0EF0):
Ressourcenleck: Objektarray (0x1249F00) war nie Gelöscht

Objektarray (0x01249F00) [Größe: 255 Byte] war erstellt mit new[]
Aufrufhierarchie:
0x004154D1(=ProjectX.exe:0x01:0144D1) C:\ProjectX\C++ Arbeitsordner\SRC\Info.cpp#43
0x004160AF(=ProjectX.exe:0x01:0150AF) C:\ProjectX\C++ Arbeitsordner\SRC\Info.cpp#191

Mal sehen, was ich damit so anfangen kann....

Kolumbus

Inzwischen ist viel passiert. Ich habe jetzt nur noch diese Fehlermeldung vom Codeguard:

CodeGuard schrieb:

Fehler 00097. 0x300010 (Thread 0x0C94):
Ressourcenleck: Objektarray (0x1249F00) war nie Gelöscht

Objektarray (0x01249F00) [Größe: 255 Byte] war erstellt mit new[]
Aufrufhierarchie:
0x0040C8FD(=ProjectX.exe:0x01:00B8FD) C:\ProjectX\Temp\SRC\Info.cpp#43
0x0040D54F(=ProjectX.exe:0x01:00C54F) C:\ProjectX\Temp\SRC\Info.cpp#191
0x5205010F(=vcl100.bpl:0x01:06F10F)
0x5204FD52(=vcl100.bpl:0x01:06ED52)
0x00401FE0(=ProjectX.exe:0x01:000FE0) c:\programme\borland\bds\4.0\include\vcl\Forms.hpp#1008
0x0040CFA8(=ProjectX.exe:0x01:00BFA8) C:\ProjectX\Temp\SRC\Info.cpp#150

------------------------------------------

Das ist Zeile 43:

char  *subBlockName = new char[255];

Das ist Zeile 191:

MyVersionInfo applVersion;

Was muss ich jetzt verfolgen? Ich kann mit der Fehlermeldung mal wieder nicht viel anfangen. Heißt das, es fehlte ein delete für dieses Objektarray?

Morris Szyslak

Fast. Es fehlt ein delete[].

Th

Falls das nur eine lokale Variable sein sollte, dann würde ich dafür eher eine Stack-Variable nehmen:

char subBlockNam[255];

... denn dann benötigt man auch kein 'delete []' mehr.

Kolumbus

Ich hab' eine Stack-Variable daraus gemacht. Es war kein Grund ersichtlich, warum für das Array dynamisch Speicher reserviert werden musste ( der dann hinterher nicht mal freigegeben wurde) - war mal wieder ein Programmteil der nicht von mir war. Mehrere Methoden der betroffenen Unit verwenden auch dieses Array als Stack-Variable im selben Kontext (nämlich nur als temporären Puffer). Dankeschön soweit.

Jetzt schreibt CodeGuard vom BDS2006 keine Fehler mehr und BCB3 beschwert sich auch über nix (selbes Projekt mit identischem Code in anderem Ordner), wenn ich jedoch die exe starten will: *.exe hat ein Problem festgestellt und muss beendet werden. Das Ganze 3mal. Wenn ich jedes Mal auf "Informationen zu diesem Fehler" drücke erhalte ich 2mal:

Problemsignatur:
AppName: ProjectX.exe
AppVer: 0.0.0.0
ModName: kernel32.dll
ModVer: 5.1.2600.2991
Offset: 00012a5b

Und 1mal:

Problemsignatur:
AppName: ProjectX.exe
AppVer: 0.0.0.0
ModName: kernel32.dll
ModVer: 5.1.2600.2991
Offset: 0000de9c

Sprich, das Projekt läuft nicht, aber beide mir zur Verfügung stehenden IDE's zeigen keine Fehler an. Ich habe inzwischen alle Module auf ungenutzte oder nicht / falsch initialisierte Variablen und Zeiger abgeklappert, mir fällt nichts mehr auf... Kann jemand eine Aussage zu den geposteten Problemsignaturen machen? Was kann ich damit anfangen?

Kolumbus

Hallo Gemeinschaft,

ich hab mir mal nen Spaten geholt und das Thema hier wieder ausgegraben. Ich habe derzeit ein fertiges Projekt auf dem Tisch, an dem ich nur ein paar kleine Änderungen machen soll. Die fertig compilierte Executable des Projektes lässt sich überall starten, nur auf meinem Rechner nicht... Mal wieder drei Fehlermeldungen, wie immer. 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?

Edit: PS: Die anderen Rechner sind alle keine Dual-Cores.

audacia

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. Was hätte ich da nur ohne Virtual PC gemacht...

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?

Edit: PS: Die anderen Rechner sind alle keine Dual-Cores.

Du könntest das Programm auf deinem Rechner mit Prozessor-Affinität starten (z.B. mit einem Tool wie diesem hier).

Sollte das aber die Fehlerquelle sein, so ist es wohl auf mangelhafte Thread-Synchronisation zurückzuführen. Und nicht alle Fehler, insbesondere nicht derartige, lassen sich mit statischen oder dynamischen Analyse-Tools aufspüren.

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.

Kolumbus

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!

Kolumbus

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?

Kolumbus

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

audacia

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.

Kolumbus

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

audacia

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.