Delphiで文字列をリークする方法

Question

先日、デルファイで文字列をリークさせる方法について、同僚と話していました。デフォルトでは、文字列は参照カウントされ、自動的に割り当てられるので、通常は何も考慮せずに手動で割り当て、サイズの計算、またはメモリ管理をする必要はありません。

しかし、私は一度、文字列をリークする方法があることを覚えています（リークしたオブジェクトに含めることなく）。それは、参照によって文字列を渡し、それが渡されたルーチン内から大きなスコープからアクセスすることと関係があるようです。ええ、私はそれがあいまいであることを知っています、それが私がここで質問している理由です。

Answer 1

実は、CONSTまたは非constのとして文字列を渡すことで参照カウントの期間に同じですDelphi 2007 and 2009.文字列がCONSTとして渡されたときにアクセス違反が発生するケースがありました。ここで私はthisは私が考えていたものに似ているかもしれないと思う問題1

type 
    TFoo = class 
    S: string; 
    procedure Foo(const S1: string); 
    end; 

procedure TFoo.Foo(const S1: string); 
begin 
    S:= S1; //access violation 
end; 

var 
    F: TFoo; 
begin 
    F:= TFoo.create; 
    try 
    F.S := 'S'; 
    F.Foo(F.S); 
    finally 
    F.Free; 
    end; 
end. 

Answer 2

2番目の段落の問題についてはわかりませんが、レコードで漏れた文字列で1回噛まれました。

文字列を含むレコードでFillChar（）を呼び出すと、refカウントと動的に割り当てられたメモリのアドレスが0で上書きされます。文字列が空でない限り、メモリがリークします。これを回避する方法は、占有するメモリをクリアする前に、Finalize（）をレコードにコールすることです。

残念なことに、を呼び出すFinalize（）ファイナライズが必要なレコードメンバーがない場合、コンパイラのヒントが発生します。 Finalize（）コールでヒントを無音にしたが、後でレコードに文字列メンバーを追加したときに、コールのコメントを忘れてしまったので、リークが発生した。幸運にも、私は一般的にFastMMメモリマネージャをデバッグモードで最も冗長で妄想的な設定で使用しているので、漏れは気付かれませんでした。

Finalize（）コールが不要な場合は、コンパイラのヒントはそれほど良いことではないでしょうが、はるかに良いIMHOです。

Answer 3

いいえ、私はそんなことは起こり得ないと思います。文字列変数は期待していない値を取得する可能性がありますが、メモリがリークすることはありません。このことを考えてみましょう：

ここ

var 
    Global: string; 

procedure One(const Arg: string); 
begin 
    Global := ''; 

    // Oops. This is an invalid reference now. Arg points to 
    // what Global used to refer to, which isn't there anymore. 
    writeln(Arg); 
end; 

procedure Two; 
begin 
    Global := 'foo'; 
    UniqueString(Global); 
    One(Global); 
    Assert(Global = 'foo', 'Uh-oh. The argument isn''t really const?'); 
end; 

Oneの引数はそうおそらく、constとして宣言され、それは変更されません。しかし、Oneは、仮パラメータの代わりに実際のパラメータを変更することで回避します。プロシージャTwoは、Oneの引数がconstであることを "知っている"ので、実際のパラメータが元の値を保持することを期待しています。アサーションは失敗します。

文字列はリークしませんでしたが、このコードでは、ダングリングリファレンスを文字列として取得する方法を示しています。 Argは、ローカル別名Globalです。 Globalを変更しましたが、Argの値は変更されず、constとして宣言されているため、関数への入力時に文字列の参照カウントがインクリメントされませんでした。再割り当てGlobalは、参照カウントをゼロに落とし、その文字列は破棄されました。 varとしてArgを宣言すると同じ問題が発生します。値を渡すことでこの問題が解決されます。 （UniqueStringへの呼び出しは、文字列が参照カウントされていることを確認するだけです。そうでなければ、参照カウントされていない文字列リテラルである可能性があります）。シンプルなタイプは免疫です。

文字列をリークする唯一の方法は、文字列以外のものとして扱うか、非型対応のメモリ管理機能を使用することです。Mghie's answerには、FillCharを使用して文字列以外の文字列として文字列を処理する方法が記載されています。非タイプ認識メモリ機能には、GetMemおよびFreeMemが含まれます。例：

type 
    PRec = ^TRec; 
    TRec = record 
    field: string; 
    end; 

var 
    Rec: PRec; 
begin 
    GetMem(Rec, SizeOf(Rec^)); 
    // Oops. Rec^ is uninitialized. This assignment isn't safe. 
    Rec^.field := IntToStr(4); 
    // Even if the assignment were OK, FreeMem would leak the string. 
    FreeMem(Rec); 
end; 

2つの方法で修正できます。一つはInitializeとFinalizeを呼び出すことです：

GetMem(Rec, SizeOf(Rec^)); 
Initialize(Rec^); 
Rec^.field := IntToStr(4); 
Finalize(Rec^); 
FreeMem(Rec); 

他のタイプの認識機能を使用することです：

New(Rec); 
Rec^.field := IntToStr(4); 
Dispose(Rec); 

Answer 4

です。文字列リークの逆で、早く収集される文字列です。

var 
    p : ^String; 

procedure InitString; 
var 
    s, x : String; 
begin 
    s := 'A cool string!'; 
    x := s + '. Append something to make a copy in' + 
      'memory and generate a new string.'; 

    p := @x; 
end; 

begin 
    { Call a function that will generate a string } 
    InitString(); 

    { Write the value of the string (pointed to by p) } 
    WriteLn(p^); // Runtime error 105! 


    { Wait for a key press } 
    ReadLn; 
end. 

Answer 5

文字列をリークする別の方法は、threadvar変数として宣言することです。詳細は、my questionを参照してください。そして解決方法については、the solution on how to tidy itを参照してください。