Schreibzugriffe auf Speicheradresse überwachen?

[uligerhardt]

Hallo zusammen!

In einem unserer Programme wird gelegentlich bei manchen Kunden offenbar eine Variable überschrieben (möglicherweise durch einen fehlerhaften Move- oder FillChar-Aufruf). Wenn der Fehler auch auf den Entwicklerrechnern auftreten würde, würde ich einen Datenhaltepunkt auf die Variable setzen. Gibt es so etwas Ähnliches auch zum Ausliefern?

[Union]

FastMM und Eurekalog bieten so etwas. Allerdings kannst Du das nicht ausliefern, da die Performance natürlich in die Knie geht. Praktisch wird das so realisiert, dass die Speicherbereiche mit bestimmten Bitmustern gefüllt werden und bei jedem Lese- und Schreibvorgang verglichen. Normalerweise findet man aber beim Test diese Fehler ganz schnell. Ich würde Dir einen Testlauf mit FastMM und FullDebugMode empfehlen.

Mit dem Haltepunkt findest Du Fehler auch nur zufällig, denn je nach Speichersituation erfolgt ein Schreiben bei einem Buffer overrun an eine ganz andere Stelle. Mal ist es, ganz auffällig, eine auch für den Kunden direkt ersichtliche Auswirkung. Es kann aber auch gerne ein Datenbankpuffer sein oder was anderes Nettes. Du hast dort eine tickende Zeitbombe die unbedingt zu entschärfen ist.

[uligerhardt]

Zitat von Union:

FastMM und Eurekalog bieten so etwas. Allerdings kannst Du das nicht ausliefern, da die Performance natürlich in die Knie geht.

Das wird auch nur eine temporäre Spezialversion.

Zitat von Union:

Praktisch wird das so realisiert, dass die Speicherbereiche mit bestimmten Bitmustern gefüllt werden und bei jedem Lese- und Schreibvorgang verglichen. Normalerweise findet man aber beim Test diese Fehler ganz schnell. Ich würde Dir einen Testlauf mit FastMM und FullDebugMode empfehlen.

Wie kann ich die Prüfung denn aktivieren und möglichst auf Schreibzugriffe auf diese eine Variable eingrenzen?

Zitat von Union:

Mit dem Haltepunkt findest Du Fehler auch nur zufällig, denn je nach Speichersituation erfolgt ein Schreiben bei einem Buffer overrun an eine ganz andere Stelle. Mal ist es, ganz auffällig, eine auch für den Kunden direkt ersichtliche Auswirkung. Es kann aber auch gerne ein Datenbankpuffer sein oder was anderes Nettes.

Der Fehler kommt dort, wo er überhaupt kommt, recht "zuverlässig".

Zitat von Union:

Du hast dort eine tickende Zeitbombe die unbedingt zu entschärfen ist.

Drum frag ich ja.

[Union]

Du mußt FastMM4.pas als erste in der .dpr einbinden und im Pfad oder bei der exe die FastMM_FullDebugMode.dll bereitstellen. Dann noch {$define FullDebugMode} in der FastMMOptions.inc aktivieren.

Dann machst Du einen neuen Build und gehst die verdächtigen Teile des Programms durch. Beim Beenden wird Dir ein ausführlicher LeakReport mit Adressen, Stacktrace etc. angezeigt und als Datei gespeichert.

[Zacherl]

Um ein Leak sollte es sich ja hier aber eher nicht handeln, eher um einen Heap Overflow. Probier mal GFlags:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Damit bin ich vor geraumer Zeit mal ziemlich erfolgreich einer (vorher) nicht zu findenden Heap Corruption auf die Schliche gekommen.

[uligerhardt]

Irgendwie raff ich's nicht. Ich hab mal ein Testprojektchen gestrickt:

Delphi-Quellcode:

program OverwriteTest;

uses
  FastMM4,
  Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  ReportMemoryLeaksOnShutdown := True;
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows,
  Messages,
  SysUtils,
  Variants,
  Classes,
  Graphics,
  Controls,
  Forms,
  Dialogs,
  ExtCtrls,
  StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    procedure Log(const AMessage: string);
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

var
  Start: Integer;
  Victim: Integer;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Log('before');
  FillChar(Start, 2 * SizeOf(Start), 0);
  Log('after');
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Start := 123;
  Victim := 456;
  Log('ctor');
end;

procedure TForm1.Log(const AMessage: string);
begin
  OutputDebugString(PChar(AMessage + ': ' + IntToStr(Start) + '/' + IntToStr(Victim)));
end;

end.

Wenn jetzt der Benutzer auf Button1 klickt, hätte ich gerne die Info, dass der FillChar-Aufruf im Speicherbereich von Victim rumgeschrieben hat.

[uligerhardt]

Zitat von Zacherl:

Um ein Leak sollte es sich ja hier aber eher nicht handeln, eher um einen Heap Overflow.

Nicht mal Heap, sondern eine ganz banale globale Variable.

Zitat von Zacherl:

Probier mal GFlags:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Damit bin ich vor geraumer Zeit mal ziemlich erfolgreich einer (vorher) nicht zu findenden Heap Corruption auf die Schliche gekommen.

Ich hab mir das mal durchgelesen. Soweit ich das verstehe, funktioniert das auch nur für Speicher auf dem Heap, oder?

[Zacherl]

Zitat von uligerhardt:

Ich hab mir das mal durchgelesen. Soweit ich das verstehe, funktioniert das auch nur für Speicher auf dem Heap, oder?

Kanns dir nicht genau sagen, aber ist sicher nen Versuch wert. Ich weiß nicht, wie Delphi mit primitiven Datentypen umgeht, aber zumindest Objekte sind auf jeden Fall Heap allocated. Würde dir auf jeden Fall mal den "Full" Mode empfehlen, bei dem das Tool die Pages mit PAGE_GUARD protected.

[himitsu]

Zitat von uligerhardt:

Soweit ich das verstehe, funktioniert das auch nur für Speicher auf dem Heap, oder?

Der Stack liegt am Ende auch nur irgendwo im Heap.

[Union]

Das Problem bei dem Test ist, dass FillChar verwendet wird. Und dort verwendet wohl auch FastMM die Routine aus system.pas so dass kein Monitoring möglich ist.