Nach Update auf Delphi12 startet compiliertes Prog nicht mehr. Fehler bei LoadResStri

[bernau]

Ich bin von Delphi 11 auf Delphi 12 umgestiegen. Eigentlich alles gut. Nun habe ich festgestellt, dass ein Programm nicht mehr startet.

Breakpoint auf die erste Zeile im Projekt-Quelltext gesetzt. Dort kommt das Programm erst gar nicht an.

Also mit F7 gestartet und festgestellt, dass beim initialisieren der Units der Fehler auftritt.

In der Procedure InitUnits (Zeile 242003) aus der Unit System werden die einzelnen Units initialisiert.

Delphi-Quellcode:

// Unit System 

procedure InitUnits;
var
  Count, I: Integer;
  Table: PUnitEntryTable;
  P: Pointer;
begin
{$IF defined(EXTERNALLINKER)}
  dbk_RTL_initialized := 0;
{$ENDIF}
  if InitContext.InitTable = nil then
    exit;
  Count := InitContext.InitTable^.UnitCount;
  I := 0;
  Table := InitContext.InitTable^.UnitInfo;
{$IF defined(LINUX) and not defined(EXTERNALLINKER)}
  Inc(PByte(Table), InitContext.Module^.GOT);
{$ENDIF}
  try
    while I < Count do
    begin
      P := Table^[I].Init;
      Inc(I);
      InitContext.InitCount := I;
      if Assigned(P) and Assigned(Pointer(P^)) then
      begin
{$IF defined(MSWINDOWS)}



        TProc(P)();  // <----- Hier wird zum Initialisieren in die jeweilige Unit gesprungen.



{$ELSEIF (defined(POSIX) and defined(CPUX86)) and defined(ASSEMBLER)}
        CallProc(P, InitContext.Module^.GOT);
{$ELSE}
        TProc(P)();
{$ENDIF}
      end;
    end;
  except
    FinalizeUnits;
    raise;
  end;
{$IF defined(EXTERNALLINKER)}
  dbk_RTL_initialized := 1;
{$ENDIF}
end;

Bei der Unit "Soap.XSBuiltIns" lande ich sofort in der letzten QuellcodeZeile

Delphi-Quellcode:

// Letzte Zeilen der Unit Soap.XSBuiltIns

procedure InitXSTypes;
begin
  RemClassRegistry.RegisterXSClass(TXSDateTime, XMLSchemaNameSpace, 'dateTime', '',True);
  RemClassRegistry.RegisterXSClass(TXSTimeInstant, XMLSchemaNameSpace, 'timeInstant', '', True);
  RemClassRegistry.RegisterXSClass(TXSTime, XMLSchemaNameSpace, 'time', '', True);
  RemClassRegistry.RegisterXSClass(TXSDate, XMLSchemaNameSpace, 'date', '', True);
  RemClassRegistry.RegisterXSClass(TXSDuration, XMLSchemaNameSpace, 'duration', '', True);
  RemClassRegistry.RegisterXSClass(TXSDuration, XMLSchemaNameSpace, 'timeDuration', '', True);
  RemClassRegistry.RegisterXSClass(TXSHexBinary, XMLSchemaNamespace, 'hexBinary', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'decimal', '', True);
  {
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'integer', '', True);
  }
  RemClassRegistry.RegisterXSClass(TXSString, XMLSchemaNamespace, 'string', '', True);
  RemClassRegistry.RegisterXSClass(TXSBoolean, XMLSchemaNamespace, 'boolean', '', True);
  RemClassRegistry.RegisterXSClass(TXSInteger, XMLSchemaNamespace, 'int', '', True);
  RemClassRegistry.RegisterXSClass(TXSLong, XMLSchemaNamespace, 'long', '', True);

  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'negativeInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'nonNegativeInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'nonPositiveInteger', '', True);
  RemClassRegistry.RegisterXSClass(TXSDecimal, XMLSchemaNamespace, 'positiveInteger', '', True);
end;

end. // <---- Von TProc(P)(); landet der Debugger hier

Dann geht es weiter mit F7 in die Procedure _InitResStringImports

Delphi-Quellcode:

procedure _InitResStringImports(InitTable: Pointer);

//...
//...
//...

@@ustring:
        CALL    LoadResStringU

Dort geht es weiter mit F7 in die Procedure LoadResStringU

Delphi-Quellcode:

function LoadResStringU(ResStringRec: PResStringRec): UnicodeString;
begin
  Result := UnicodeString(LoadResString(ResStringRec));
end;

Und zum Schluss geht es weiter mit F7 in die Procedure LoadResString

Delphi-Quellcode:

function LoadResString(ResStringRec: PResStringRec): string;
var
  Buffer: array [0..4095] of Char;
begin  // <--- Hier landet der Debugger. Mit F8 erscheint sofort die Exception
  if ResStringRec = nil then Exit;
  if Assigned(LoadResStringFunc) then
    Exit(LoadResStringFunc(ResStringRec));
  if ResStringRec.Identifier < 64*1024 then
    SetString(Result, Buffer,
      LoadString(FindResourceHInstance(ResStringRec.Module^),
        ResStringRec.Identifier, Buffer, Length(Buffer)))
  else
    Result := PChar(ResStringRec.Identifier);
end;

Dann erscheint sofort die Exception

Code:

Im Projekt comcept3.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0xce93d58d: access of address 0xce93d58d' aufgetreten.

Ab hier stehe ich auf dem Schlauch.

Hat jemand eine Idee, wo ich weiter suchen kann?

[dummzeuch]

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

[bernau]

Zitat von dummzeuch:

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding.

[MichaelT]

Howdy,

Auch auf die Gefahr, dass ich mich unbeliebt mache. Clean und Build?

lg
Hoppy

Zitat von bernau:

Zitat von dummzeuch:

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding.

[bernau]

Zitat von MichaelT:

Howdy,

Auch auf die Gefahr, dass ich mich unbeliebt mache. Clean und Build?

lg
Hoppy

Zitat von bernau:

Zitat von dummzeuch:

Da hilft wohl nur die CPU-Ansicht weiter. Dann kannst Du hoffentlich herausfinden, bei welchem Zugriff die AV auftritt. Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Ich habe es befürchtet. Ist ja nicht so mein Ding.

Nope

[himitsu]

Zitat von dummzeuch:

Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Eigentlich sollte dort im Beginn garnicht viel drin sein,
außer dass ein billiger Bytepuffer (8 KB) auf den Stack gepusht wird, bzw. eigentlich sogar einfach nur der Stackpointer um diese 8 KB verschoben wird.
OK, und vorher der Zeiger-Wert für den Parameter und den Zeiger des Result auch noch auf den Stack, aber alles nichts Wildes.

[dummzeuch]

Zitat von himitsu:

Zitat von dummzeuch:

Es scheint irgendwas im Initialisierungs-Code der Procedure zu sein.

Eigentlich sollte dort im Beginn garnicht viel drin sein,
außer dass ein billiger Bytepuffer (8 KB) auf den Stack gepusht wird, bzw. eigentlich sogar einfach nur der Stackpointer um diese 8 KB verschoben wird.
OK, und vorher der Zeiger-Wert für den Parameter und den Zeiger des Result auch noch auf den Stack, aber alles nichts Wildes.

Eben: Eigentlich. Aber wenn es da knallt, muss das von irgendwas dort ausgelöst werden.

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Kas Ob.'s Vermutung, dass da der Stack kaputt ist, könnte man damit auch überprüfen.

Ohne weitere Informationen raten wir hier nur rum.

[Kas Ob.]

Zitat von dummzeuch:

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Kas Ob.'s Vermutung, dass da der Stack kaputt ist, könnte man damit auch überprüfen.

Ohne weitere Informationen raten wir hier nur rum.

Well this will not useful at all after the exception because the EIP already pointing to inaccessible address.

But there is a way, and bernau words "Ist ja nicht so mein Ding." made me stop explaining how to catch this, though it is not hard nor late to learn, so here we go :
1) put breakpoint on this line "if Assigned(P) and Assigned(Pointer(P^)) then"
2) run the application until it stop on the above breakpoint
3) open the CPU View and watch the stack pointer and its content like this in the screenshot
Stack.png
We don't care about anything else, just the two values at the blue arrow, what are we watching for, these values on that breakpoint must stay the same all the time and on every execution.
4) hit RUN on the debugger or F9 key, the debugger will stop again on that break point, and the blue arrow (the stack pointer) should be pointing to the same values each time, on side note all the vlaue above also should be not changed in this case, it might change in different case, but that is different talk for different place.
5) keep hiting F9 until you see different values, this means the last initialization section had corrupted the stack already, we stop here , without closing the debugger.
6) from the local variables for this thread, you willse the value inside P, it should be in hex, something like $xxxxxxxx.
7) on my IDE XE8, there is
IDE Main Menu -> Search -> Go to Address , open it and write the P address, and don't forget the $ , the place for this option might be different in newer IDEs, i have no idea.
8) you will land on the initialization that caused the stack to corrupt, investigate there.

[dummzeuch]

Zitat von Kas Ob.:

Zitat von dummzeuch:

@Bernau: Selbst wenn man nicht selbst versteht, was da genau passiert, hilft es vielleicht, einen Screenshot des CPU-Fensters vor der Anweisung, die die Exception auslöst, hier zu posten.

Well this will not useful at all after the exception because the EIP already pointing to inaccessible address.

Yes, that's why I wrote "*vor* der Anweisung, die die Exception auslöst".

[Kas Ob.]

Zitat von Kas Ob.:

1) put breakpoint on this line "if Assigned(P) and Assigned(Pointer(P^)) then"
.

correction the breakpoint should be at "P := Table^[I].Init;"