Beobachtetes Speicherleckproblem beim Ausführen von OpenVINO™ Image Classification Async C++ Beispiel

• Führen Sie OpenVINO™ Image Classification Async C++ Sample durch Ausführen der _CrtMemDumpAllObjectsSince-Methode aus.
• Speicherleck wie folgt erkannt:

  Dumping objects ->{253771} normal block at 0x000001BAE43B8700, 112 bytes long.Data: <@ ; 0 ; > 40 8F 3B E4 BA 01 00 00 30 98 3B E4 BA 01 00 00{253770} normal block at 0x000001BAE43B9830, 112 bytes long.Data: < ; @ ; > 00 87 3B E4 BA 01 00 00 40 8F 3B E4 BA 01 00 00{253769} normal block at 0x000001BAE31B4590, 128 bytes long.Data: <@ ; @ ; > 40 8F 3B E4 BA 01 00 00 40 8F 3B E4 BA 01 00 00{253768} normal block at 0x000001BAE3218760, 16 bytes long.Data: < v > 00 76 80 08 F8 7F 00 00 00 00 00 00 00 00 00 00{253767} normal block at 0x000001BAE43B8F40, 112 bytes long.Data: <0 ; ; > 30 98 3B E4 BA 01 00 00 00 87 3B E4 BA 01 00 00{253766} normal block at 0x000001BAE32173B0, 16 bytes long.Data: < u > E8 75 80 08 F8 7F 00 00 00 00 00 00 00 00 00 00 : Object dump complete.

CrtDumpMemoryLeaks() meldet alle Objekte, die nicht zerstört wurden (auch globale Objekte). Sie waren also in der Lage, das Problem zu reproduzieren, indem sie nur openvino /openvino.hpp (ohne Ausführung in main) oder mit DEDEFINE ... Makro aus der gflags-Bibliothek (wird vom Beispiel verwendet) ohne jegliche OpenVINO™. Laut der obigen Analyse kann ein solcher Bericht nicht als echtes Produktspeicherleck behandelt werden.

Verwenden Sie Desinfektionsmittel oder Valgrind-Tools als zuverlässigere Tools zur Überprüfung von Speicherlecks.

Weitere Informationen zum Nachverfolgen von Speicherlecks finden Sie unter Optimieren der Speichernutzung