4. Projekt läuft nicht auf neuem 6-Core m. Win7 64 --- Gelöst ---

Projekt läuft nicht auf neuem 6-Core m. Win7 64 --- Gelöst ---

  • R

    <Edit> abgetrennt aus http://www.c-plusplus.net/forum/278955 </Edit>

    Hallo, schön dass Dich nochmal meldest.

    Ich hab jetzt auf meinem neuen 6Core Rechner mit Win7-64 jede Menge an Fehlermeldungen für mein Projekt, das schon mal lief. Da war ein Update für den Debugger dabei, der vorher beim Programmende abstürzte. Jetzt gibts aber noch mehr Fehler. Wenn ich nun auf Vista zurückgehe, dann muß ich ja schon wieder Registrieren. Ich bin nun ziemlich frustig. Vielleicht sinds ja auch meine Fehler beim Installieren. Ich finds halt sehr verworren, wie es Embarcadero macht.

    Und was sind die ISOs?

    Gruß Rudi

    PS: Ein frühere Version läuft ohne Debugger einwandfrei, halt nur mit 66% statt 100% bei 4 Cores.

    0
  • A

    rudiM schrieb:

    Ich hab jetzt auf meinem neuen 6Core Rechner mit Win7-64 jede Menge an Fehlermeldungen für mein Projekt, das schon mal lief.

    Fehlermeldungen welcher Art? Übersetzungsfehler, Laufzeitfehler, oder etwas ganz anderes?

    Derartige Migrations- und Portierungsprobleme ("but it works on my machine!") sind übrigens nur eine der Problemklassen, die sich mit dem Einsatz von Continuous Integration, Unit-Tests und Versionsverwaltung systematisch vermeiden lassen.

    rudiM schrieb:

    Wenn ich nun auf Vista zurückgehe, dann muß ich ja schon wieder Registrieren.

    Das ist Symptombekämpfung. Wenn der Compiler Fehler in deinem Programm meldet, liegt das wahrscheinlich daran, daß dein Programm fehlerhaft ist und nicht der Compiler.

    rudiM schrieb:

    Und was sind die ISOs?

    Die DVD-Images (.iso ist die übliche Dateiendung) der zugehörigen Produkt-DVDs. Wenn du das aktuelle Image bei Embarcadero herunterlädst und ich mich nicht gewaltig irre, dann hast du darin bereits alle verfügbaren Updates.

    rudiM schrieb:

    PS: Ein frühere Version läuft ohne Debugger einwandfrei, halt nur mit 66% statt 100% bei 4 Cores.

    Ich weiß nicht, was du mir damit sagen willst.

    0
  • R

    Hallo.

    Ich hab nach der Installation meiner eigenen DVD das RAD-Studio mit BCB installiert. Anschließend von der DVD2 das LMD-Tool.
    Das ist soweit gelaufen mit meinem Projekt. Als ich jedoch mein Programm unter dem Debugger laufen ließ, Stürzte der Debugger beim offiziellen Programmende jedes mal ab. Der gesamte BCB mußte jedes mal neu gestartet werden.
    Da war ich froh, als ich las, dass es einen Hotfix für den Debugger unter Win7 gibt. Allerdings ist mir unklar ob 32- oder 64 Bit-Win7. (ich hab Win7-64).

    Bei der Gelegenheit habe von dieser Page (http://cc.embarcadero.com/myreg/c_builder) auch die Updates 1-4 und das Helpupdate 1 rundergeladen, und nach Vorschrift installiert.
    Vielleicht wäre das angebotene ISO besser gewesen, aber mich schreckten die 1,9 GB ab.

    Fehlerablauf dieser Installation:
    BCB läd ok. Mein Projekt wird richtig geladen. Es läßt sich ohne Fehler erzeugen.
    Beim Projektstart kommt die Debugger-Exception:

    Im Projekt DeepChaosV2.exe ist eine Exception der Klasse EExternalException mit der Meldung 'Externe Exception C0000025' aufgetreten.
    Anhalten Fortsetzen Hilfe

    (laut Hilfe eine Betriebssystem-Exception)
    Button Anhalten geht. Programm beenden geht (rotes Viereck)
    Bei erneuten Programmstart kommt die Meldung wieder.
    Bei Button Fortsetzen kommt die Meldung wieder.
    Bei Fortsetzen mit ex-typ-ignorieren kommt:

    Im Projekt DeepChaosV2.exe ist eine Exception der Klasse EStackOverflow mit der Meldung 'Stack-Überlauf' aufgetreten.

    Im Ereignisprotokoll:

    Erste Gelegenheit für Exception bei $775BB727. Exception-Klasse EStackOverflow mit Meldung 'Stack-Überlauf'. Prozess DeepChaosV2.exe (2960)

    Auch bei Neustart von BCB bleibt es bei Stacküberlauf.
    Beim direkten Starten meines Projektes ohne BCB passiert gar nichts. Wenn ich als Admin starte kommt: "Programm funktioniert nicht mehr"

    rudiM schrieb:

    Eine frühere Version läuft ohne Debugger einwandfrei, halt nur mit 66% statt 100% bei 4 Cores.

    Ich wollte zeigen (zugegeben etwas pralerisch), dass mein Projekt mit der alten Compilierung schon gelaufen ist und auch unter Win7-64 läuft. Da ich nichts am Code geändert habe, sollte es doch mit der Neuinstallation auch laufen. Das deutet evtl darauf hin, daß schon beim compilieren etwas schief läuft.

    Falls Ihr keinen Rat habt, werde ich es doch mal mit dem ISO versuchen.
    Gruß Rudi

    0
  • R

    Hallo,

    ich hab versucht die Ursache zu finden, indem ich das Prog von Anfang an durchsteppe. Gleich beim Start bei

    Application->CreateForm(__classid(TDCWd), &DCWd);

    wird das Modul

    Modul laden: UxTheme.dll. Ohne Debug-Infos. Basisadresse: $72BE0000. Prozess DeepChaosV2.exe (1028)

    geladen. Danach kommt die Meldung im Ereignisprotokoll;

    Erste Gelegenheit für Exception bei $76AEB727. Exception-Klasse EStackOverflow mit Meldung 'Stack-Überlauf'. Prozess DeepChaosV2.exe (1028)

    Seltsammer Weise werden ohne Breakpunkt alle Module geladen bevor diese Meldung erscheint.

    Gruß Rudi

    PS: Ich ein Neues Projekt mit einer einfachen VCL-Anwendung programmiert. Die läuft soweit gut 😕

    0
  • A

    Wenn du die Stacküberlauf-Exception erhältst, wie sieht dann der Call-Stack aus?

    0
  • R

    Erste Gelegenheit für Exception bei $76AEB727. Exception-Klasse EStackOverflow mit Meldung 'Stack-Überlauf'. Prozess DeepChaosV2.exe (1736)

    :76aeb727 KERNELBASE.RaiseException + 0x58
    :0053960e ___raiseDebuggerException + 0x1A
    :005396eb ; ___raiseDebuggerException
    :772e8799 ; ntdll.dll
    :772e876b ; ntdll.dll
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :005389d5 __ExceptionHandler + 0x1E
    :772e876b ; ntdll.dll
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    .....
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :0044e252 ; D:\DC\Debug\DeepChaosV2.exe
    :0044e49a ; D:\DC\Debug\DeepChaosV2.exe
    :0044dd02 __linkproc__ TReader::ReadDataInner(const Classes::TComponent 😉 + 0x1A
    :0044dce4 ; D:\DC\Debug\DeepChaosV2.exe
    :004530f2 __linkproc__ TComponent::ReadState(Classes::TReader 😉 + 0x6

    0
  • A

    Uah.

    Aktiviere mal die Debug-Bibliotheken (in C++Builder 2009 erfordert das vor allem das Linken ohne Laufzeit-Packages und dynamische RTL). Dann solltest du einen detaillierteren Call-Stack bekommen.

    0
  • R

    Meinst Du das:

    ......
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :772a010f ntdll.KiUserExceptionDispatcher + 0xf
    :5004ed72 rtl120.@Classes@TReader@ReadPrefixqqrr46System@%Sett18Classes@TFilerFlag$iuc00iuc2%ri + 0xee :5004efba ; C:\\Windows\\SysWOW64\\rtl120.bpl :5004e822 rtl120.@Classes@TReader@ReadDataInnerqqrp18Classes@TComponent + 0x1a
    :5004e804 rtl120.@Classes@TReader@ReadDataqqrp18Classes@TComponent+0x6c:50057c1artl120.@Classes@TComponent@ReadStateqqrp18Classes@TComponent + 0x6c :50057c1a rtl120.@Classes@TComponent@ReadStateqqrp15Classes@TReader + 0x6

    Ich hab mal das Häckchen bei Laufzeit Packages gemacht. Wie das Aktivieren gehen soll hab ich nicht gefunden. Sorry.

    0
  • A

    rudiM schrieb:

    Ich hab mal das Häckchen bei Laufzeit Packages gemacht.

    Ich sagte ohne Laufzeit-Packages, nicht mit 😉

    Die Debug-Bibliotheken sind dann eigentlich schon aktiviert. Und da du steppen kannst, scheinst du auch mit dem Debug-Build zu arbeiten. Kannst du denn Haltepunkte im VCL-Quelltext setzen (den findest du in $(BDS)\source\Win32\vcl\)?

    Damit sind für mich allerdings die Ferndiagnosemöglichkeiten ausgeschöpft. Was du noch machen könntest:

    • Die Revision des Quelltextes zum Zeitpunkt deiner "erfolgreichen Kompilierung" mit dem aktuellen Stand vergleichen und speziell auf Unterschiede in den DFM-Dateien achten.
    • Einen Haltepunkt im Konstruktor von TDCWd setzen. Allerdings suggeriert der Call-Stack, daß das Programm gar nicht erst dort ankommt, sondern irgendwo im VCL-Serialisierungsmechanismus hängenbleibt. Das wiederum läßt auf irgendwelche Komponenten schließen, die sich danebenbenehmen (vielleicht diese LMD-Komponenten?).
    • Was du also auch versuchen könntest, wäre, ein Branch zu machen und dann in der *.dfm-Datei schrittweise Komponenteneigenschaften herauszunehmen, bis der Fehler nicht mehr auftritt.
    0
  • R

    Hallo,
    jetzt wird es ernst. Vor 25 Jahren hab ich die Methode der "Reduzierung" schon mal erfolgreich angewandt. Einfach Komponete für Komponete entfernen bis der Fehler nicht mehr auftaucht. Hat funktioniert, war aber auwändig. Jetzt die LMD-Tools rauszuschmeißen kommt einer neuprogrammierung gleich. Naja, ein paar Tage wird es wohl dauern.
    Die letzte erfolgreiche Compilierung hat bezüglich des Hauptformulars, das den Absturz verursacht, keine Veränderungen im Code. Aber im Hauptformular sind fast alle LMD-Tools eingebaut.
    Ich werd dann mal nen single-Step von anfang an versuchen.
    Gruß Rudi

    Ps.: es gibt doch den Remote-Debugger. Wäre der für Dich brauchbar?

    0
  • A

    rudiM schrieb:

    Wäre der für Dich brauchbar?

    Wenn du das bezahlst, können wir drüber reden.

    Jedenfalls brauchst du nicht gleich ein ganzes Komponenten-Package zu beseitigen. Sieh erst einmal zu, daß du meine Ratschläge befolgst, alles mit Debug-Infos kompilierst und linkst (im Idealfall kannst du sowohl im VCL- als auch im LMD-Quelltext, sofern vorhanden, Breakpoints setzen) etc.

    0
  • R

    Hallo,
    Ich hab mal etwas Debugged:

    Application->CreateForm(__classid(TDCWd), &DCWd);         Hier passiert der Stacküberlauf

    dann kommt er hier in Classes.pas an:

    procedure TReader.ReadDataInner(Instance: TComponent);
var
  OldParent, OldOwner: TComponent;
begin
  while not EndOfList do ReadProperty(Instance);
  ReadListEnd;
  OldParent := Parent;
  OldOwner := Owner;
  Parent := Instance.GetChildParent;
  try
    Owner := Instance.GetChildOwner;
    if not Assigned(Owner) then Owner := Root;
    while not EndOfList do ReadComponent(nil);       diese ReadComponent() ruft aber diese ReadDataInner rekursiv auf.
    ReadListEnd;
  finally
    Parent := OldParent;
    Owner := OldOwner;
  end;
end;

    Letzter Teil von Classes.ReadComponent():

    else
        begin
          AddSubComponentsToLoaded(Result);
          FLoaded.Add(Result);
        end;
      except
        if ComponentCreated then Result.Free;
        raise;					<<<<<<<<<<< Hier????
      end;
  finally
    Parent := OldParent;
    FLookupRoot := OldLookupRoot;
  end;
end;						Genau 147 mal wird das End hier erreicht

    Nach den 147 Durchläufen kommt das Prog bei "raise;" an. Dann noch 2 mal. Dann verschwindet das Prog im Nirvana mit besagten Stackoverflow.
    Da ich im Formular ca.320 Componenten habe, hab ich mal die Reihenfolge verändert. Dann wären es weniger als 147 Durchläufe gewesen, wenn eine Componente der Auslöser wäre. War aber wieder 147.
    Könnt Ihr schon was Orakeln???
    Grup Rudi

    0
  • R

    Hallo,

    Es war tatsächlich das 147. Objekt.
    Es ist ein TLMDEdit von LMD-Tools. Ich hatte diesem Editfeld einen SpezialButton zugeordet, aber im Programm noch nicht verwendet. Nach Entfernung nur dieses Buttons liefs wieder rund. Dies war im gesamten Projekt jedoch der einzige Button dieser Art, so dass ich nicht sagen kann, wer der eigentliche Auslöser war, LMDTools, BCB oder ich.

    Jetzt aber extra schöne Weihnachten :xmas2: :xmas2: :xmas2: :xmas1:
    Rudi

    0
Anmelden zum Antworten