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

[Kas Ob.]

Hi,

Zitat von bernau:

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 von Kas Ob.:

Hi,

Zitat von bernau:

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.

[bernau]

Zitat von Uwe Raabe:

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?

[MichaelT]

Ist das Projekt dynamisch gelinkt?

Zitat von bernau:

Zitat von Uwe Raabe:

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 von Kas Ob.:

Hi,

Zitat von bernau:

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)();"

[bernau]

Zitat von Kas Ob.:

Zitat von Kas Ob.:

Hi,

Zitat von bernau:

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".

[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 von 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 !

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.