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

[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