2

シャットダウン時にクラッシュし始めたプログラムがあります。デバッガーには次のように表示されます。

---------------------------
Debugger Exception Notification
---------------------------
Project Project1.exe raised exception class $C0000005 with message 'access violation at 0x00a69099: read of address 0x70687efe'.

[続行] をクリックすると、同じエラーが表示されます。「Break」をクリックすると、IDE は EMemLeaks.pas ユニットを開きます。
ここに画像の説明を入力

プログラムは、すべてのデバッグ情報を含めて「デバッグ」モードでコンパイルされます。マップファイルは詳細に設定されています。
ここに画像の説明を入力

また、私のコードでは Free の代わりに FreeAndNil のみを使用します (ただし、サードパーティのライブラリでは使用しません)。

StackTrace (Delphi IDE から):
ここに画像の説明を入力

次の場合、クラッシュは表示されません:
- Eureka プラグインが無効になっている、または
- Eureka プラグインが有効になっていて、プログラムが IDE の外部で実行されている

クラッシュは、「Application.Run」の後のどこかに表示されます。これは、すべてのクリーンアップ コードが実行されたことを意味します。右？

質問:
1. 上記の設定は正しいですか? そうでない場合、何を変更しますか？
2. デバッガーが問題を生成したコードにカーソルを置くことができない場合、それはどういう意味ですか?
3. これは、エラーが私のコードの外にあることを示していますか?

更新(すべての道はユーレカに通じています):

プロジェクトのすべてのコードを削除することができました。これが残っているすべてです：

INTERFACE
USES
  Winapi.Windows, Vcl.Forms,  Vcl.StdCtrls, Vcl.ComCtrls, Vcl.Controls, Vcl.ExtCtrls, System.Classes,
  IdAntiFreeze, IdFTP, IdGlobal, IdBaseComponent, IdComponent, IdTCPConnection, IdTCPClient, IdExplicitTLSClientServerBase, Vcl.Grids;

TYPE
  TfrmDownloader = class(TForm)
    pgCrtl          : TPageControl;
    Splitter        : TSplitter;
    tabMain         : TTabSheet;
    lblTop          : TLabel;
    pnlGrid         : TPanel;
    Panel1: TPanel;
    IdFTP1: TIdFTP;
    btnUpdates: TButton;
    StringGrid1: TStringGrid;
    Panel2: TPanel;
    btnDownStart: TButton;
    RichEdit1: TRichEdit;
  private
  protected
  public
  end;

VAR
   frmDownloader: TfrmDownloader;
IMPLEMENTATION {$R *.dfm}
end.

プロジェクトはまだクラッシュします。

さらに、GenerateCrash というプロシージャを実行すると、プログラムをシャットダウンした (そして Eureka がアクティブな) ときとまったく同じ AV が生成されます: $C0000005.

procedure GenerateCrash;   
VAR T: TObject;
begin
 EmptyDummy;
 FreeAndNil(T);
 T.ClassName;
end;

考えさせられます。右？さらに、EurekaLog のサポートはこの問題を放棄しました。おそらく彼らはこの問題について知っており、将来のバージョンで修正される予定です（私はアクセスできません）。各リリースで、かなりの数の重大なバグがリストされていることがわかります。「v7.0 Hot-fix 1」のリリース以降、110 の機能が導入され、 271 のバグが修正されました。基本的に、新しい機能が導入されるたびに、ほぼ 3 つのバグも導入されました。EurekaLog は、これまでで最もバグの多いソフトウェア製品の 1 つに違いありません!

4

1 に答える 1

4

デバッガーは、例外が発生したソース コードで利用可能なデバッグ情報を持っている場合、ソース コードに I をドロップします。コードのデバッグ情報が含まれます。ただし、RTL/VCL コードなどの場合はそうではありません。二重解放の場合、コードに欠陥がある場合でも、RTL コードで例外が発生することがよくあります。

DCU のデバッグを有効にすると、成功する可能性が高くなります。これにより、デバッガーは RTL/VCL コードのデバッグ情報にアクセスできるようになります。

ただし、EurekaLog スタック トレースを見てください。これを説明するために必要なすべてが含まれているはずです。

スタック トレースを見ると、FastMM のデバッグ バージョンを実装する外部 DLL で AV が発生しています。そのコードを見て何も学べません。問題を解決するには、スタック トレースを調べる必要があります。アクセス違反が発生した場合、答えは見つかりません。メモリ破損エラーは、この性質のものであることがよくあります。エラーは、欠陥から遠く離れて発生します。

debug FastMM は、後で無視する AV 例外を発生させる場合があることに注意してください。これらは非常に誤解を招く可能性があります。それはあなたのために起こっている可能性があります。ただし、シャットダウン時にこれに遭遇したことはないので、実際に欠陥があると思われます。

とは言っても、欠陥は EurekaLog またはその構成方法にある可能性があります。私のアドバイスが必要な場合は、EurekaLog ではなく madExcept をお勧めします。

于 2016-08-31T07:26:28.327 に答える