3

アプリケーションがサービスとして実行されている場合、 FastMM4 for Delphi がメモリ リークを詳細なファイルに報告するために提供するのと同じ手法は機能しますか? もちろん、ベスト プラクティスは、最初に単体テストと単純なスタンドアロン アプリケーションを作成し、サービス環境の外でリークを見つけることです。

4

5 に答える 5

2

はい。サービスの実行に使用されるアカウントに、ログ ファイルを書き込むための十分な権限がある場合に限ります。

于 2009-06-01T19:20:52.283 に答える
0

私は今同じ挑戦をしています。私はこれを試しましたが、少なくとも今のところは機能しません。サービスは独自のログファイルを書き込むことができるため、アカウントには十分な権限があります。FullDebugModeをオンにして、dllを追加しました。両方とも、IDEオプションを介してLogMemoryLeakDetailToFileをオンにしました。コードでは、適切な領域がコンパイラーによって認識されていることがわかります。たとえば、エラーを引き起こした場合、コンパイラーはそれを報告します。また、FastMMコードをデバッグできません。ブレークポイントを設定すると、無視されます。そのレポートが表示される可能性のあるすべてのローカルハードディスクを検索しましたが、見つかりません。「管理-サービス」からサービスを開始および停止します。すべてうまくいき、起動しますが、レポートはありません。通常の実行可能ファイルで同じことを行うと、すべてうまくいきます。FastMM478とDelphi2007を使用しています。

マーク

于 2009-06-03T07:03:06.530 に答える
0

OK、出力、ログファイル、またはメッセージボックスが表示されない場合がある別の理由を見つけました......

エラーがなければ、出力は作成されません。

したがって、FASTMM478 が機能するかどうかをテストするには、プログラムで次のようなエラーを意図的に作成します。

//作成し、破棄しない testToMakeError := TStringList.Create; for I := 0 to 100 do testToMakeError.Add('foobar');

どこかでエラーを起こし、プログラムがフィードバックを返してくれなかった理由を探るのに 1 日を費やしたのではないかと思いました。

マルク

于 2009-06-04T10:22:43.493 に答える