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.

[Kas Ob.]

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

What did happen ?
Either : (these what came to mind, may be there is more)
1) a unit in initialization section directly had corrupted the stack, aka overwrite it,
2) a unit in initialization section performed an operation that pushed/fooled the memory manager to corrupt a global variable or singleton class, that lead to corrupted stack,
3) a unit in initialization section corrupted the stack by using the wrong calling convention.

Example : loading a library (DLL) with broken declaration (wrong call convention, like missing stdcall where it is needed or using it when it is not needed) could lead to this.

In all cases the error root is in the initialization section of one unit being initialized before "Soap.XSBuiltIns".

[bernau]

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

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. :x

[bernau]

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

What did happen ?
Either : (these what came to mind, may be there is more)
1) a unit in initialization section directly had corrupted the stack, aka overwrite it,
2) a unit in initialization section performed an operation that pushed/fooled the memory manager to corrupt a global variable or singleton class, that lead to corrupted stack,
3) a unit in initialization section corrupted the stack by using the wrong calling convention.

Example : loading a library (DLL) with broken declaration (wrong call convention, like missing stdcall where it is needed or using it when it is not needed) could lead to this.

In all cases the error root is in the initialization section of one unit being initialized before "Soap.XSBuiltIns".

The Unit called before "Soap.XSBuiltIns" is "Web.HTTPApp".

No Code in the initialization section

Delphi-Quellcode:

function TCustomWebFileDispatcher.DispatchRequest(Sender: TObject;
  Request: TWebRequest; Response: TWebResponse): Boolean;
var
  LDispatcher: TWebBrokerDispatchFileRequest;
begin
  LDispatcher := TWebBrokerDispatchFileRequest.Create(Self,
    Request, Response);
  try
    Result := LDispatcher.DispatchFileRequest;
  finally
    LDispatcher.Free;
  end;
end;

initialization
finalization
  FreeAndNil(FContentParsers);
end.

[Uwe Raabe]

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

[MichaelT]

Howdy,

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

lg
Hoppy

Zitat:

Zitat von bernau (Beitrag 1538010)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

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. :x

[bernau]

Zitat:

Zitat von MichaelT (Beitrag 1538022)

Howdy,

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

lg
Hoppy

Zitat:

Zitat von bernau (Beitrag 1538010)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

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. :x

Nope :cry:

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1538013)

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

Daran habe ich auch schon gedacht. Ich verwende keine selbst erstellten Ressourcen.

Habe die Ressourcen-Dateien *.rc, *.res und *.dres gelöscht. Die werden neu Aufgebaut. Fehler immer noch da.

Gibt es noch irgendwelche Ressourcen-Dateien, die ich vielleicht übersehen haben könnte?

[Kas Ob.]

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

Keep going back, i mean the empty initialization contains a simple ret instruction, which will work always, but some unit initialization before that did ruin you stack.
And to be exact, that exception you are receiving is hardware raised by a ret instruction while the stack value is $ce93d58d instead of the address pointing to right after "TProc(P)();"

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

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:

Zitat von himitsu (Beitrag 1538036)

Zitat:

Zitat von dummzeuch (Beitrag 1537999)

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.

[MichaelT]

Ist das Projekt dynamisch gelinkt?

Zitat:

Zitat von bernau (Beitrag 1538032)

Zitat:

Zitat von Uwe Raabe (Beitrag 1538013)

Anhand der Stelle mit dem Fehler würde ich auch eine defekte Resource in Betracht ziehen.

Daran habe ich auch schon gedacht. Ich verwende keine selbst erstellten Ressourcen.

Habe die Ressourcen-Dateien *.rc, *.res und *.dres gelöscht. Die werden neu Aufgebaut. Fehler immer noch da.

Gibt es noch irgendwelche Ressourcen-Dateien, die ich vielleicht übersehen haben könnte?

[Kas Ob.]

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@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
Anhang 56940
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:

Zitat von Kas Ob. (Beitrag 1538043)

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@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:

Zitat von dummzeuch (Beitrag 1538045)

Zitat:

Zitat von Kas Ob. (Beitrag 1538043)

Zitat:

Zitat von dummzeuch (Beitrag 1538039)

@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". ;-)

Sorry, my bad.

[Kas Ob.]

Zitat:

Zitat von Kas Ob. (Beitrag 1538043)

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

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

[jaenicke]

Kann es sein, dass du irgendwelche Delphiunits kopiert und modifiziert eingebunden hast?

Ich verstehe das doch richtig:
Andere Projekte gehen?

Dann würde ich ein frisches Projekt nehmen, an der gleichen Stelle speichern und die Units wieder einfügen. Zuerst kannst du ja die Soap.XSBuiltIns mal einzeln in die uses packen.

Wenn es dann mit allen Units geht, liegt es an den Projekteinstellungen.

Wenn nicht, muss es an einer Unit liegen. Dann würde ich die der Reihe nach rauswerfen bis es geht. Dauert etwas, weil es ja jeweils kompilieren muss, aber sollte zum Ergebnis führen. Wenn wirklich Speicher kaputt ist, kann es natürlich sein, dass das auch nicht reicht, aber dann müsste man eh konkret schauen, warum es an der Stelle knallt, sprich den Speicher prüfen.

[bernau]

Fehler gefunden. Puh.

Schuld war eine Unit "gnuGettext.pas", welche irgendwie beim Umzug auf Delphi 12 und bei der Anpassung der Quelltexte in eine bestehende Unit "reingerutscht" ist.

Ich habe keine Funktion dieser Unit genutzt. Weis der Geier weshalb die auf einmal in der Uses einer Unit auftaucht.

Alleine macht "gnuGettext.pas" keine Probleme. Allerdings in Kombination mit "Soap.XSBuiltIns" knallt es.

Konnte ich dann einfach nachvollziehen. Neues Projekt, beide Units in die Uses des Projektquelltextes rein und starten. Knallt sofort.

Habe in meiner alten Delphi11 Installation nachgeschaut. Dort ist diese Unit nicht eingebunden. Also Entwarnung. Es hat nicht wirklich etwas mit dem Umstieg von Delphi 11 auf Delphi 12 zu tun. Das Problem saß vor dem Bildschirm.

Ich will die Unit gnuGettext nicht schlecht reden. Meine Version ist aber von 2010 und ich weis nicht, ob es dafür Updates gibt und wofür die überhaupt gebraucht wird. Habe diese nie genutzt.

Danke noch mal für eure Tipps.

[bernau]

Zitat:

Zitat von Kas Ob. (Beitrag 1538035)

Zitat:

Zitat von Kas Ob. (Beitrag 1538007)

Hi,

Zitat:

Zitat von bernau (Beitrag 1537995)

Hat jemand eine Idee, wo ich weiter suchen kann?

Look in every "initialization" section being called before this one, most likely the exact unit before "Soap.XSBuiltIns", this one is innocent and the error somewhere earlier.

Keep going back, i mean the empty initialization contains a simple ret instruction, which will work always, but some unit initialization before that did ruin you stack.
And to be exact, that exception you are receiving is hardware raised by a ret instruction while the stack value is $ce93d58d instead of the address pointing to right after "TProc(P)();"

You're right. Finally i dived in everey TProc(P) and looked what happend in the initialization-section "and" all "class constructors" wich also where initialized in the InitUnits. Because of about 900 steps, i missed the initialization-part of "gnugettext".

[himitsu]

Nja, die gnuGetText hookt halt die ResourceString-Funktionen.
Je nach Version/Umsetung könnte man diesen Teil aber auch entfernen/deaktivieren, falls man nur selbst "manuell" Texte übersetzten wollte, z.B. mit der _()-Funktion.

Wer weiß was XSBuiltIns macht

[bernau]

Zitat:

Zitat von jaenicke (Beitrag 1538048)

Kann es sein, dass du irgendwelche Delphiunits kopiert und modifiziert eingebunden hast?

Ja. Leider. Wie oben beschrieben.:oops:

Zitat:

Zitat von jaenicke (Beitrag 1538048)

Ich verstehe das doch richtig:
Andere Projekte gehen?

Ja tatsächlich. Der Fehler tritt nur auf, wenn "gnuGetText" UND "Soap.XSBuiltIns" in der Uses steht.

Zitat:

Zitat von jaenicke (Beitrag 1538048)

Kann es sein, dass du irgendwelche Delphiunits kopiert und modifiziert eingebunden hast?

Ich verstehe das doch richtig:
Andere Projekte gehen?

Dann würde ich ein frisches Projekt nehmen, an der gleichen Stelle speichern und die Units wieder einfügen. Zuerst kannst du ja die Soap.XSBuiltIns mal einzeln in die uses packen.

Wenn es dann mit allen Units geht, liegt es an den Projekteinstellungen.

Wenn nicht, muss es an einer Unit liegen. Dann würde ich die der Reihe nach rauswerfen bis es geht. Dauert etwas, weil es ja jeweils kompilieren muss, aber sollte zum Ergebnis führen. Wenn wirklich Speicher kaputt ist, kann es natürlich sein, dass das auch nicht reicht, aber dann müsste man eh konkret schauen, warum es an der Stelle knallt, sprich den Speicher prüfen.

Ich habe es fast so gemacht. Ich habe ein leeres Projekt erzeugt und dann nacheinander die benutzen Units des Programm zugefügt. Zuserst die, die wenig Abhängigkeiten haben, dann komplexere units und zum Schluss Forms. Bis dahin bin ich aber nicht gekommen. der Fehler ist schon vorher aufgetreten. DAnn nach und nach wieder die Units entfernt, bis eine Handvoll übrig bleiben. Danach ging es sehr schnell.

[MichaelT]

Große Freude!

Danke für die Info.

Zitat:

Zitat von bernau (Beitrag 1538049)

Fehler gefunden. ,,,

Danke noch mal für eure Tipps.

[Kas Ob.]

This line is cause :
https://github.com/zijianhuang/Commo...text.pas#L2454

Code:

  // replace Borlands LoadResString with gettext enabled version:
  HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringA);

The implementation of both LoadResStringA and LoadResStringW are not compatible system.LoadResString.
https://github.com/zijianhuang/Commo...s#L63C1-L67C66

Code:

// Unicode-enabled way to get resourcestrings, automatically translated
// Use like this: ws:=LoadResStringW(@NameOfResourceString);
function LoadResString(ResStringRec: PResStringRec): widestring;
function LoadResStringA(ResStringRec: PResStringRec): ansistring;
function LoadResStringW(ResStringRec: PResStringRec): widestring;

This override casting by hooking between string and widestring cause Delphi memory manager to corrupt memory at arbitrary places and luckily for you it happens at the stack at this stage !

Though this behavior might be easier to be found by using resource leak finder like Nexus Quality Suite Code Watch https://www.nexusdb.com/support/index.php?q=node/27156
Or may be even any memory corruption tracker could find it earlier, like FastMM in full debug, MadShi, EurekaLog, or Code Watch.

Why Code Watch ? because it is sensitive for hooking as it does use them, so confliction or hidden hooks could be found easier.

[dummzeuch]

Zitat:

Zitat von bernau (Beitrag 1538049)

Schuld war eine Unit "gnuGettext.pas", welche irgendwie beim Umzug auf Delphi 12 und bei der Anpassung der Quelltexte in eine bestehende Unit "reingerutscht" ist.

gnuGetText dient der Übersetzung von Text und Formularen. Dabei wird u.a. die LoadResString-Funktion gehookt, was Dein Problem erklären könnte.

Der Orignal-Autor Lars Dybdahl, ist schon seit Jahren von der Bildfläche verschwunden. Zuletzt habe ich diese Unit und die zugehörigen Tools mehr oder eher weniger gepflegt, weil ich noch Zugriff auf das Repository habe. Unter Delphi 12 habe ich sie allerdings nie getestet und vermutlich funktioniert sie auch nicht mit FMX und schon gar nicht mit anderen Platformen als Win32.

Die aktuelle Version gibt es übrigens auf SourceForge.

[dummzeuch]

Zitat:

Zitat von Kas Ob. (Beitrag 1538057)

This line is cause :
https://github.com/zijianhuang/Commo...text.pas#L2454

Code:

  // replace Borlands LoadResString with gettext enabled version:
  HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringA);

The implementation of both LoadResStringA and LoadResStringW are not compatible system.LoadResString.
https://github.com/zijianhuang/Commo...s#L63C1-L67C66

Code:

// Unicode-enabled way to get resourcestrings, automatically translated
// Use like this: ws:=LoadResStringW(@NameOfResourceString);
function LoadResString(ResStringRec: PResStringRec): widestring;
function LoadResStringA(ResStringRec: PResStringRec): ansistring;
function LoadResStringW(ResStringRec: PResStringRec): widestring;

This override casting by hooking between string and widestring cause Delphi memory manager to corrupt memory at arbitrary places and luckily for you it happens at the stack at this stage !

The current code looks like this:

Delphi-Quellcode:

// Unicode-enabled way to get resourcestrings, automatically translated
// Use like this: ws:=LoadResStringW(@NameOfResourceString);
function LoadResString(ResStringRec: PResStringRec): widestring;
function LoadResStringW(ResStringRec: PResStringRec): UnicodeString;
function PLoadResString(const szMsgCtxt: MsgIdString; ResStringRec: PResStringRec): widestring;
function PLoadResStringW(const szMsgCtxt: MsgIdString; ResStringRec: PResStringRec): UnicodeString;

Delphi-Quellcode:

  // replace Borlands LoadResString with gettext enabled version:
  {$ifdef UNICODE}
  HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringW);
  {$else}
  HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringA);
  {$endif}

No idea whether this fixes the problem, but I use it for most of our internal tools at work with Delphi 2007 and 10.2 and haven't experienced any inexplicable AVs.
That code is from at least 2012 (when it was copied to SourceForge from now defunct Berlios, so any older history is lost). That version you found must be even older. But on the other hand, the dxgettext project dates back to the 1990ies where it of course started out as non-Unicode-aware.

[Kas Ob.]

Never used gnugettext or DxGetText in my life ! so yes i am not sure which is the latest or maintained.

In all cases these functions should not even consider using widestring to begin with, these with widestring should be removed, and as for declaring a specific function with unicodestring or ansistring is also not my favorite, they just should be string, to be future proof with RTL yet backward compatible.

[milo]

Hey Gerd,

da sind wir ja froh, dass es nicht an Delphi 12 gelegen hat....

Gruß :D Michael

[himitsu]

Zitat:

Zitat von dummzeuch (Beitrag 1538058)

und vermutlich funktioniert sie auch nicht mit FMX

Nja, grundlegend sollte FMX unter Windows die selben Funktion der WinAPI und RTL nutzen, also müsste das dort auch gehen.

[jaenicke]

// bringt hier gar nichts - Denkfehler

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1538079)

Zitat:

Zitat von dummzeuch (Beitrag 1538058)

und vermutlich funktioniert sie auch nicht mit FMX

Nja, grundlegend sollte FMX unter Windows die selben Funktion der WinAPI und RTL nutzen, also müsste das dort auch gehen.

Es geht dabei nicht um WinAPI sondern um die Objektstruktur. dxGetText greift auf Formulare und die Komponenten darauf zu und übersetzt bestimmte Properties (in der TranslateComponent Procedure). Das dürfte nicht kompatibel zu FMX sein. Nicht, dass ich groß Ahnung von FMX hätte, alle unsere (internen) Programme sind VCL und ich sehe bisher auch keinen Grund, das zu ändern.