Hilfe zur Speicherleck Suche benötigt

[TurboMagic]

Hallo,

ich versuche gerade in der DEC (https://github.com/MHumm/DelphiEncry...ee/development,
commit 750d068) ein Speicherleck in der gerade in Entwicklung befindlichen BCrypt Umsetzung zu finden.

Nur gehen mir gerade echt die Ideen aus, trotz FastMM4 FullDebugMode.
Das Leck muss irgendwo in Hash.CalcBytes in Zeile 5214 von DECHash.pas liegen,
doch trotz Debugger sind mir inzwischen die Ideen ausgegangen.

Wie kann man es reproduzieren?

1. Diese Version runterladen in ein leeres Verzeichnis
2. In Install\SetIDEPaths Projekt öffnen und ausführen
3. IDE neu starten und Projektgruppe unter Source Verzeichnis laden
4. Im DUnit Test Projekt FastMM4 in den Uses auskommentieren, es sei denn, man
hat es vorrätig. Falls ja die Units davon in den Source Ordner und die DLL in
Compiled\BIN_IDE22.0_Win32_Debug kopieren.
5. DUnit Test Projekt den TestTHash_BCrypt/TestCryptBSDFormat Test alleine ausführen.
Nach Schließen des DUnit GUI RUnners sollte man ein 36 Byte Leck der Klasse "Unknown"
gemeldet bekommen.

Wer kann mir helfen?

Grüße
TurboMagic

[sahimba]

Ob Dir das was nützt weiß ich nicht. Die 36 Bytes kommen hierher:

$00503C67 Vcl.Graphics TResourceManager.ChangeResource (1981)
$0050507B Vcl.Graphics Brush.SetData (3457)
$0050511D Vcl.Graphics TBrush.SetColor (3518)
$005FB6EE Vcl.Controls TWinControl.WndProc (10581)
$005F622F Vcl.Controls TControl.Perform (7323)
$005F4F48 Vcl.Controls TControl.SetColor (6561)
$006D5D92 TestFramework TTestResult.RunSuite (1879)
$006D6226 TestFramework TAbstractTest.Run (1993)
$006E2C12 GUITestRunner TGUITestRunner.RunTheTest (1562)
$006E2CE0 GUITestRunner TGUITestRunner.RunActionExecute (1582)

In Vcl.Graphics TResourceManager.ChangeResource Zeile 1981 steht
GraphicsObject.FResource := AllocResource(ResData);

Bist Du sicher, dass diese 36 Bytes aus Deinem Code kommen? Ich bekomme dasselbe Ergebnis, wenn ich einen anderen Test ausführe.

[TurboMagic]

Danke für das Testen.

Naja, ich kann die Meldung weg bekommen,
wenn ich den CalcBytes Aufruf durch dessen
Ergebnis ersetze...

Das sieht für mich verdächtig aus.
Mein Callstack sieht auch etwas anders aus
und enthält DEC Code.

Grüße
TurboMagic

[TurboMagic]

Hier noch mehr Informationen:

1. Die Speicherlecks treten nur bei den BCrypt Tests auf! Deselektiere ich alle BCrypt
Tests und lasse die anderen 1200 Tests durchlaufen gibt's keine SPeicherlecks!

2. Hier was ich für den im ersten Post erwähnten test als Stacktrace bekomme:

Code:

A memory block has been leaked. The size is: 36

This block was allocated by thread 0xB84, and the stack trace (return addresses) at the time was:
40726D [System][@ReallocMem$qqrrpvi]
40E1AF [System][DynArraySetLength$qqrrpvpvipi]
40E316 [System][@DynArraySetLength$qqrv]
669A51 [DECHashAuthentication.pas][DECHashAuthentication][TDECPasswordHash.GetDigestInCryptFormat][1576]
6B1455 [TestDECHash.pas][TestDECHash][TestTHash_BCrypt.TestCryptBSDFormat][6372]
62F461 [TestFramework][TTestCase.Invoke]
62F528 [TestFramework][TTestCase.RunTest]
62B06B [TestFramework][TTestResult.RunTestRun]
62B2EB [TestFramework][TTestResult.Run]
62B7DC [TestFramework][TTestResult.ShouldRunTest]
62C380 [TestFramework][TAbstractTest.RunWithFixture]

The block is currently used for an object of class: Unknown

Wie komme ich da weiter?

Grüße
TurboMagic

[jaenicke]

Das Problem ist der Aufruf an ProtectBuffer hier:

Delphi-Quellcode:

procedure TDECPasswordHash.DoDone;
begin
  inherited;

  ProtectBuffer(FSalt, SizeOf(FSalt));
  SetLength(FSalt, 0);
end;

Du übergibst FSalt statt FSalt[0] und machst damit das Array kaputt. Da danach die Längenangabe des Arrays 0 ist, wird auch nichts mehr freigegeben.

[TurboMagic]

Danke!
Du bist mein Held!
Ja, das war die Ursache!
Eine gesonderte Erwähnung in NOTICE.TXT gibt's aber keine
Warum? Weil du da schon drin stehst!

Grüße
TurboMagic

[jaenicke]

Zitat von TurboMagic:

Eine gesonderte Erwähnung in NOTICE.TXT gibt's aber keine
Warum? Weil du da schon drin stehst!

Du kannst auch gern meinen Realnamen eintragen: Sebastian Jänicke

Noch ein Wort zur Fehlersuche:
Ich habe zwar manuell gesucht, indem ich den Weg des Arrays verfolgt habe und schlicht den Ausführungszeiger testweise über die Methode hinweg geschoben habe, so dass ich gemerkt habe, dass es daran liegt, und dann habe ich das Problem auch schon gesehen. Aber wäre der betreffende Quelltext länger gewesen oder hätte ich es nicht so schnell gefunden, hätte ich es anders gemacht.

Ich denke, dass das allgemein interessant sein könnte, weil es nicht jeder kennt, deshalb schreibe ich kurz etwas zum Thema Datenhaltepunkte.
Was macht ein Datenhaltepunkt?
Ein Datenhaltepunkt hält an, wenn eine Speicherstelle verändert wird.
Warum hilft uns das hier?
Weil im Speicher des Arrays außerhalb der Elemente geschrieben wurde.

Heißt:
In TDECPasswordHash.SetSalt wird FSalt zugewiesen. Bis zum Freigeben des Speichers dürfte nun nur noch eine Änderung an den Elementen passieren. Also setzt man einen Haltepunkt auf FSalt nach der Zuweisung. Das Ergebnis ist, dass an genau der Fehlerstelle angehalten wird:



Datenhaltepunkte helfen enorm, wenn Speicher falsch überschrieben wird, vorausgesetzt man weiß vorher an welcher Stelle etwas überschrieben wird.

[TurboMagic]

Hallo,

danke für den Tipp mit dem Datenhaltepunkt.
Was müsste ich im vorliegenden Fall dort eintragen?
Dass es die gibt wusste ich schon, bei meinen bisherigen versuchen die zu nutzen hatte
das aber aus irgendwelchen Gründen nie richtig geklappt...

Die NOTICE.TXT hab' ich auch wie gewünscht geändert.

Grüße
TurboMagic

[jaenicke]

Zitat von TurboMagic:

danke für den Tipp mit dem Datenhaltepunkt.
Was müsste ich im vorliegenden Fall dort eintragen?

Ganz einfach: FSalt