Speicherverluste in Boost Asio

Question

Ich habe Client/Server-App. Interaktion über Boost.Asio implementiert.

Ich erstellte Komponententest, um lange laufende Übertragung von Daten zu überprüfen. Während des Tests wurde ein Speicherleck erkannt. Task-Manager zeigt mir, dass Speicherverbrauch ständig wächst - bis zu 35 MB pro 10min. Bericht am Ende des Tests hergestellt wird, enthält diese:

Result StandardError: Detected memory leaks! 
Dumping objects -> 
{14522} normal block at 0x00E8ADC0, 16 bytes long. 
Data: < _M} Y   > B0 5F 4D 7D F9 59 F2 02 F4 E9 E6 00 CC CC CC CC 
{14012} normal block at 0x00E8B280, 16 bytes long. 
Data: < v    > C0 76 A4 00 94 01 00 00 98 01 00 00 F0 D2 E3 00 
{14011} normal block at 0x00E74B38, 12 bytes long. 
Data: <   > 00 00 00 00 9C 01 00 00 98 01 00 00 
{14007} normal block at 0x00E745F8, 8 bytes long. 
Data: < L  > E0 4C E5 00 00 00 00 00 
{14006} normal block at 0x00E54CB8, 60 bytes long. 
Data: < v   4 > E4 76 A4 00 D0 D3 B0 00 00 00 00 00 34 80 E3 00 
{13724} normal block at 0x00E710F8, 385 bytes long. 
Data: <    > 03 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
{13722} normal block at 0x00E85C58, 28 bytes long. 
Data: < F _ _  > F2 B6 46 00 B4 5F E3 00 A0 5F E3 00 BC 96 E7 00 
{13720} normal block at 0x00E6F9B8, 80 bytes long. 
Data: <wxF    > 77 78 46 00 FC FF FF FF 00 00 00 00 CC CC CC CC 
{13700} normal block at 0x00E6DFD0, 88 bytes long. 
Data: <    > C8 A4 A4 00 01 00 00 00 01 00 00 00 00 00 00 00 
… 
Data: <` X L > 60 8E E0 00 58 17 E2 00 CD 4C F7 EA 
{153} normal block at 0x00DF0070, 12 bytes long. 
Data: <`  kf > 60 8D E0 00 98 00 E2 00 15 6B 66 0E 
{151} normal block at 0x00DF0038, 12 bytes long. 
Data: <   .g> 20 86 E0 00 E0 FC E1 00 9D B7 2E 67 
{149} normal block at 0x00DF0658, 12 bytes long. 
Data: <  G > A0 89 E0 00 00 00 00 00 47 01 D5 11 
{147} normal block at 0x00DF0268, 12 bytes long. 
Data: <`   > 60 84 E0 00 A8 F5 E1 00 ED 8C AA BA 
{145} normal block at 0x00DF0230, 12 bytes long. 
Data: <  ' " > 20 84 E0 00 00 11 E2 00 27 B0 22 00 
{143} normal block at 0x00DF0690, 12 bytes long. 
Data: <` P KnOQ> 60 88 E0 00 50 04 E2 00 4B 6E 4F 51 
{141} normal block at 0x00DF0540, 12 bytes long. 
Data: <`  > 7> 60 82 E0 00 00 0A E2 00 3E 0D 9E 37 
{139} normal block at 0x00DF0620, 12 bytes long. 
Data: <Pq  1 > 50 71 DF 00 00 00 00 00 E5 DD 31 B5 
{137} normal block at 0x00DF0700, 12 bytes long. 
Data: < q @  #> 10 71 DF 00 40 FA E1 00 14 8B 0D 23 
{134} normal block at 0x00DF5CE0, 96 bytes long. 
Data: <h BV BV  > 68 19 E0 00 D0 42 56 00 E0 42 56 00 88 00 00 00 
{133} normal block at 0x00DF0188, 8 bytes long. 
Data: < \  > A0 5C DF 00 00 00 00 00 
{132} normal block at 0x00DF5CA0, 16 bytes long. 
Data: <    > 88 01 DF 00 D8 AA DF 00 20 AC DF 00 20 AC DF 00 
Object dump complete. 

Ich habe versucht, in Debug-Modus _crtBreakAlloc = 1000--detect_memory_leaks="allocation number" und Einstellung in Watch über Boost-Fenster Haltepunkt erwähnten Speicherzuordnungen zu setzen. Es funktioniert nicht. Vielleicht, weil Lecks nicht in meinem Code, sondern im Boost/OpenSSL Code auftreten?

Ich kann nicht herausfinden, wo Lecks auftreten. Was kann ich tun?

Windows 8, Visual Studio 2015 steigern 1,60, OpenSSL 1.0.2g

Answer 1

Teil 1: Bericht von Visual Studio über Speicherlecks

ich Boost.Asio bin mit dem Server über TLS zu kommunizieren, das heißt Boost.Asio OpenSSL verwendet.

Scheint, dass OpenSSL sich selbst initialisiert und den Speicher vor dem Ende der App nicht löscht (weil App geschlossen wird und Speicher sowieso freigegeben wird). Das ist kein großes Stück Speicher (ich weiß nicht, wie man es misst).

Als Ergebnis behandelt Visual Studio diesen Speicher als Leck. Aber es ist nicht.

(Dies ist meine Vermutung, vielleicht wahre Grund für einen solchen Bericht sonst smth Aber ich sehe keine andere mögliche Gründe..)

Teil 2:

In der Frage oben fragte ich über Speicherleck für Dutzende von Mb. Dies ist mein schlechter Code, der zu einem großen Speicherpuffer führt).

Huge Speicherverbrauch und Bericht von Visual Studio über Speicherverlust machte mich glauben, dass smth sehr falsch ist))

Buffer leicht reduziert zu viel geringeren Größe.

Answer 2

Werfen Sie einen Blick auf this post für den Umgang mit Speicherlecks unter Windows einige vorgeschlagenen Spitzen zu sehen. Scrollen Sie nach unten, schauen Sie sich nicht nur die erste Antwort an. Insbesondere könnte es sich lohnen, die makrobasierte Lösung DEBUG_NEW zu betrachten, die in der zweiten Antwort diskutiert wird. Angesichts der Tatsache, dass Boost asio weitgehend nur über Kopfzeilen verfügt, sollte Ihnen dies helfen, selbst wenn die problematischen Zuweisungen aus der Boost-Bibliothek stammen.