Externe Speicherverwaltung und COM

Question

Probleme mit der Speicherverwaltung einer Drittanbieterbibliothek. Ich habe die Quelle, aber es ist sehr komplex (COM-Zeug), voll von Makros und diesen lästigen Microsoft-Annotationen usw. und interagiert mit einer anderen Bibliothek, deren Quelle ich nicht booten muss. Jetzt haben einige schnelle Debug-Laufzeiten gezeigt, dass es Speicher verliert und ziemlich groß ist. Ich verwende ausgiebig selbst-freisetzende Zeiger wie unique_ptr und weiß, dass ich alles, was ich erstellt habe, veröffentlicht habe. Ist es meine einzige Möglichkeit zu versuchen, die Quelle zu bereinigen (und zu verstehen)?

Darüber hinaus ist es sicher, COM-Objekte mit Operator neu zuzuordnen, oder müssen sie in den COM-Heap gehen?

Answer 1

COM ist ziemlich agnostisch darüber, wie Sie Ihre eigenen COM-Objekte zuweisen. Sie werden von der Klassenfactory erstellt und Ihre IUnknown :: AddRef- und Release-Methoden behalten den Referenzzähler. Die Verwendung von Operator new in der Klassenfabrik und delete this in Release ist in Ordnung.

Sie müssen auf alle Zeiger achten, die Sie in Ihren Schnittstellenmethoden zurückgeben. Typische Automatisierungsobjekte wie BSTR und SAFEARRAY müssen tatsächlich im COM-Heapspeicher zugewiesen werden, damit der Clientcode sie freigeben kann. Ziemlich schwer, das zu vermasseln, erledigt die API die Arbeit.

Der Client-Code kann für das Leck verantwortlich sein, fummeln die Referenzzahl ist ein ziemlich Standard-COM-Fehler. Normalerweise einfach zu diagnostizieren, wenn Sie Zugriff auf die AddRef/Release-Implementierungen haben. Das Debuggen in Vista oder Win7 wird ebenfalls dringend empfohlen. Sie verfügen über einen viel besseren Heap-Manager, der Versuche nicht ignoriert, Speicher aus dem falschen Heap freizugeben.

Wenn Sie ziemlich sicher sind, dass es der COM-Server ist, der Lecks dann isolieren Sie das Problem mit den <crtdbg.h> Header-und Unit-Tests, um die Schnittstellenmethoden auszuüben.