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.

[Der schöne Günther]

Ah danke, jetzt habe sogar ich das verstanden. Und ja, unter 10.4 Sydney sieht es nun anders aus:

Delphi-Quellcode:

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

Vorher (laut dir):

Delphi-Quellcode:

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

Aus

Delphi-Quellcode:

@EmptyStringA[1]

wurde

Delphi-Quellcode:

Pointer(EmptyStringA)

. Vielen Dank. Ich konnte nichts finden weshalb das geändert worden ist. Außerdem spielen leere Strings hier ja keine Rolle. Wahrscheinlich hat sich noch mehr geändert.

PS: Unter 64 Bit funktioniert alles weiterhin wie gehabt. Wahrscheinlich steckt irgendwo ein Fehler in diesem mystischen Assemblercode.

PPS: Ich habe mal einen neuen Eintrag angelegt unter
https://quality.embarcadero.com/browse/RSP-29567

[jaenicke]

Ich kann das leider nicht reproduzieren. Ich habe es einmal mit

Delphi-Quellcode:

GetTimeUTC(Application.ExeName)

versucht. Hättest du einmal ein komplettes Beispiel mit dem Aufruf? Das würde ich bei einer Bugmeldung dringend empfehlen: Genau schreiben wie es reproduzierbar ist, wenn irgendwie möglich. Ansonsten wird dein Jira-Eintrag vermutlich als nicht reproduzierbar geschlossen...

[Der schöne Günther]

Ja, du hast Recht. Das Merkwürdige:

Delphi-Quellcode:

var dateTime := GetTimeUTC( ParamStr(0) )

liefert bei mir auch keinen Fehler. Nehme ich aber stattdessen

Delphi-Quellcode:

var timestamp := DateTimeToStr( GetTimeUTC( ParamStr(0) ) );

kommt es zur AV. Allerspätestens hier endet mein Verständnis. Jetzt müssen die Profis ran.

Ich habe dem Report eine komplette .DPR angehangen (Direktlink)

[samso]

Zitat:

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

Ah danke, jetzt habe sogar ich das verstanden. Und ja, unter 10.4 Sydney sieht es nun anders aus.

Aus

Delphi-Quellcode:

@EmptyStringA[1]

wurde

Delphi-Quellcode:

Pointer(EmptyStringA)

. Vielen Dank. Ich konnte nichts finden weshalb das geändert worden ist. Außerdem spielen leere Strings hier ja keine Rolle. Wahrscheinlich hat sich noch mehr geändert.

Danke! Diese Änderung ist ja eher kosmetischer Natur.

Delphi-Quellcode:

@EmptyStringA[1]

und

Delphi-Quellcode:

Pointer(EmptyStringA)

erzeugt - solange die Strings nicht Zerobased sind - ja exakt den gleichen Assemblercode. Damit ist diese Fehlermöglichkeit raus.

[Der schöne Günther]

Die Ursache war übrigens eine ganz andere: Die Definition von

Delphi-Quellcode:

TLoadedImage

ist in 10.4 falsch, was dann dazu führte dass in den Bereich vom AnsiString reingeschrieben wurde.

(https://quality.embarcadero.com/browse/RSP-29567)