Gestion de la mémoire externe et COM

Question

Problèmes de gestion de la mémoire d'une bibliothèque tierce. J'ai la source mais c'est très complexe (COM stuff), plein de macros et de ces annotations Microsoft agaçantes, etc, et interagit avec une autre bibliothèque dont je n'ai pas besoin de démarrer la source. Maintenant, certains runtimes de débogage rapide ont montré qu'il y avait une fuite de mémoire et d'une manière assez importante. Je fais un usage intensif de pointeurs auto-relâchés comme unique_ptr et je sais que j'ai publié tout ce que j'ai créé. Est-ce ma seule option pour essayer de nettoyer (et comprendre) la source?

De plus, est-il sûr d'allouer des objets COM avec l'opérateur new, ou doivent-ils aller dans le tas COM?

Answer 1

COM est assez agnostique sur la façon dont vous allouez vos propres objets COM. Ils sont créés par la fabrique de classes et vos méthodes IUnknown :: AddRef et Release conservent le nombre de références. En utilisant l'opérateur nouveau dans l'usine de classe et delete this dans la version est très bien.

Vous devez faire attention aux pointeurs que vous renvoyez dans vos méthodes d'interface. Des objets d'automatisation typiques tels que BSTR et SAFEARRAY doivent en effet être alloués dans le tas COM afin que le code client puisse les libérer. Assez difficile à gâcher, l'API fait le travail.

Le code client peut être responsable de la fuite, le tâtonnement du compte de référence est un bogue COM assez standard. Habituellement facile à diagnostiquer lorsque vous avez accès aux implémentations AddRef/Release. Déboguer dans Vista ou Win7 est également fortement recommandé, ils ont un gestionnaire de tas bien meilleur qui n'ignore pas silencieusement les tentatives de libérer la mémoire du mauvais tas.

Si vous êtes sûr que c'est le serveur COM qui fuit, isolez le problème avec les tests d'en-tête et d'unité <crtdbg.h> pour appliquer les méthodes d'interface.