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

rudiM

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

audacia

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

rudiM

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

audacia

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.

rudiM

Meinst Du das:

......
:772a010f ntdll.KiUserExceptionDispatcher + 0xf
:772a010f ntdll.KiUserExceptionDispatcher + 0xf
:772a010f ntdll.KiUserExceptionDispatcher + 0xf
:5004ed72 rtl120.@Classes@TReader@ReadPrefixqqrr46System@%Sett18Classes@TFilerFlag$iuc $0$ iuc2%ri + 0xee :5004efba ; C:\\Windows\\SysWOW64\\rtl120.bpl :5004e822 rtl120.@Classes@TReader@ReadDataInnerqqrp18Classes@TComponent + 0x1a
:5004e804 rtl120.@Classes@TReader@ReadData $qqrp18Classes@TComponent + 0x6c :50057c1a rtl120.@Classes@TComponent@ReadState$ qqrp15Classes@TReader + 0x6

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

audacia

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.

rudiM

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?

audacia

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.

rudiM

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

rudiM

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