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() signale tous les objets qui n’ont pas été détruits (objets globaux aussi). Ainsi, ils ont pu reproduire le problème en incluant openvino /openvino.hpp uniquement (sans aucune exécution en main), ou avec DEFINE... Macro de la bibliothèque GFLAGS (utilisée par exemple) sans OpenVINO™ du tout. Selon l’analyse ci-dessus, un tel rapport ne peut pas être traité comme une véritable fuite de mémoire de produit.
Utilisez des désinfectants ou des outils valgrind comme outils plus fiables pour vérifier les fuites de mémoire.
Vous trouverez plus de détails sur le suivi des fuites de mémoire dans Optimisation de l’utilisation de la mémoire