Code mit AnsiString lief unter 10.0 Seattle, crasht unter 10.4 Sydney

[Der schöne Günther]

Ich stehe etwas auf dem Schlauch. Folgender Code lief unter XE7, später 10.0 Seattle und, ich meine, testweise unter 10.2 Tokyo ohne Probleme:

Delphi-Quellcode:

uses System.SysUtils, System.DateUtils, WinApi.ImageHlp;

class function TLinkerTimeStamp.GetTimeUTC(const FileName: string): TDateTime;
var
    LI: TLoadedImage;
    asAnsi: AnsiString;
begin
    // Nach: http://stackoverflow.com/a/8438985/2298252
    asAnsi :=  AnsiString(FileName); //TEncoding.Default.GetBytes(FileName);

    Win32Check(MapAndLoad(PAnsiChar(asAnsi), nil, @LI, False, True));
    try
        Result := LI.FileHeader.FileHeader.TimeDateStamp / SecsPerDay + UnixDateDelta;
    finally
        UnMapAndLoad(@LI);
    end;
end;

Nun, mit 10.4, gibt es eine Access Violation beim Verlassen der Methode, wenn er die lokale Variable AnsiString finalisieren will. Das kann man auch provozieren indem man vor dem letzten

Delphi-Quellcode:

end;

noch hinzufügt:

Delphi-Quellcode:

Finalize(asAnsi);

. Die AV findet statt in

Delphi-Quellcode:

System._LStrClr(..)

durch ein (für mich mystisches) Kommando

Code:

LOCK DEC     [EDX-skew].StrRec.refCnt        { threadsafe dec refCount       }

.

Was geschieht hier, und warum geschieht es?

[Der schöne Günther]

PS: Es gibt keine Probleme wenn ich an MapAndLoad nicht mehr die

Delphi-Quellcode:

PAnsiChar(asAnsi)

, sondern stattdessen eine zusätzlich eingeführte

Delphi-Quellcode:

PAnsiChar

-Variable die auf

Delphi-Quellcode:

@asAnsi[1]

zeigt, übergebe. Übergebe ich

Delphi-Quellcode:

@asAnsi[1]

direkt statt eine zusätzliche lokale Variable einzuführen bleibt es beim Crash.

Heißt: Folgendes läuft ganz harmlos durch, wie früher:

Delphi-Quellcode:

class function TLinkerTimeStamp.GetTimeUTC(const FileName: string): TDateTime;
var
    LI: TLoadedImage;
    asAnsi: AnsiString;
    asPAnsiChar: PAnsiChar;
begin
    // Nach: http://stackoverflow.com/a/8438985/2298252
    asAnsi :=  AnsiString(FileName);
    asPAnsiChar := Addr(asAnsi[1]);

    Win32Check(MapAndLoad(asPAnsiChar, nil, @LI, False, True));
    try
        Result := LI.FileHeader.FileHeader.TimeDateStamp / SecsPerDay + UnixDateDelta;
    finally
        UnMapAndLoad(@LI);
    end;
end;

Kann das jemand erklären?

[Bernhard Geyer]

Wie ist MapAndLoad definiert?
Ich würde auch im Debugger mal Speicherauszüge anschauen vor und nach dem Aufruf.
Nicht das die Aufrufende Methode mist baut und es nur jetzt auffällt.

[himitsu]

MapAndLoad

Code:

BOOL IMAGEAPI MapAndLoad(
  PCSTR         ImageName,
  PCSTR         DllPath,
  PLOADED_IMAGE LoadedImage,
  BOOL          DotDll,
  BOOL          ReadOnly
);

Wie es in der WinApi.ImageHlp.pas aussieht, hab ich jetzt noch nicht nachgeschaut.

Hab hier nur ein 10.3.3 installiert, aber da ist es schon ein PWideChar.

Delphi-Quellcode:

type
  MarshaledAString = _AnsiChar;
  LPSTR = MarshaledAString;

function MapAndLoad(ImageName, DllPath: LPSTR; LoadedImage: PLoadedImage;
  DotDll, ReadOnly: Bool): Bool; stdcall;

In XE ist es noch PAnsiChar, was auch richtig ist, denn PCSTR ist ein C++-char, also 1 Byte groß,
und diese Funktion gibt es nur in der einen ANSI-Variante.


Fazit: Jemand hat diese Typdefinition geschrottet.

[samso]

Nicht richtig gelesen... Es heißt MarshaledAString

MarshaledAString = _PAnsiChr

[himitsu]

Ups, in der Zeile verrutscht und falsch gecopytundpastet. :oops:

Gut, dann stimmt es in 10.3.3 noch.
In 10.4 kann ich grad nicht nachsehn, aber wenn es dort auch noch stimmt, dann dreht wohl der Compiler durch.

Müsste man mal sehn wie es im Assembler zwischen den Delphiversionen aussieht, was dort generiert wird.

[samso]

Zitat:

Zitat von himitsu (Beitrag 1467063)

dann dreht wohl der Compiler durch.

Das befürchte ich auch. Wie sieht die Funktion _LStrToPChar bei Sydney denn aus? Bei dem alten Delphi ist es im wesentlichen ein Cast:

Delphi-Quellcode:

function _LStrToPChar(const S: _AnsiStr): _PAnsiChr;
begin
  if Pointer(s) = nil then
    Result := @(PEmptyString(@EmptyStringA[1])^.Nul)
  else
    Result := Pointer(s);
end;

Bzw. wird bei

Delphi-Quellcode:

PAnsiChar(asAnsi)

immer noch _LStrToPChar aufgerufen?

[hannsg]

Hallo,

ohne mich durch die Details gearbeitet zu haben: Hr. Eißing hat im Webinar zu 10.4 erwähnt, dass sich die default-Einstellung von $ZEROBASEDSTRINGS in 10.4 geändert hat. Vielleicht hat es etwas damit zu tun?

Schöne Grüße,
Meik

[Der schöne Günther]

Ich glaube das betrifft nur die iOS und Android-Compiler, oder?

Es muss ja irgend etwas mit der Referenzzählung des Strings sein, denn durch Einführen einer zusätzlichen Variable funktioniert es ja wieder.

[samso]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467121)

Es muss ja irgend etwas mit der Referenzzählung des Strings sein, denn durch Einführen einer zusätzlichen Variable funktioniert es ja wieder.

Deshalb ja meine Frage in #7.

Bei dem Aufruf

Delphi-Quellcode:

MapAndLoad(PAnsiChar(asAnsi)...

wird implizit _LStrToPChar aufgerufen. Wenn Du über die zusätzlichen Variable mit

Delphi-Quellcode:

asPAnsiChar := Addr(asAnsi[1]);

gehst, dann wird _LStrToPChar nicht benutzt.

Ich vermute, wenn Du statt

Delphi-Quellcode:

asPAnsiChar := Addr(asAnsi[1]);

wieder

Delphi-Quellcode:

asPAnsiChar := PAnsiChar(asAnsi);

benutzen würdest, kracht es wieder. Denn dann wird wieder _LStrToPChar aufgerufen. Das würde dann zeigen, dass es nicht an der zusätzlichen Variablen liegt, sondern am Aufruf von _LStrToPChar.