Sur Sandboxing une 3e partie qui fuit mémoire DLL

Question

Je cherche un moyen de guérir au moins les symptômes d'une DLL qui fuit je dois utiliser. Alors que la bibliothèque (OpenCascade) prétend fournit un gestionnaire de mémoire, j'ai pour l'instant incapable de le faire libérer toute la mémoire allouée elle.

Je souhaite au moins de mettre les appels à ce module dans un « bac à sable », afin de garder ma demande de ne pas perdre la mémoire alors que l'OCC-module est même pas en cours d'exécution plus.

Ma question est: Alors que je me rends compte que ce serait de le faire, UGLY HACK (tm) est-il possible de pré-allouer une portion de mémoire à utiliser spécifiquement par les bibliothèques, ou de construire une sorte de bac à sable autour afin que je puisse suivre ce que les zones de mémoire ils ont utilisé afin de les libérer moi-même quand je suis fini?

Ou serait-ce à hack un laid et je devrais essayer de résoudre les problèmes autrement?

Answer 1

La seule façon fiable consiste à séparer l'utilisation de la bibliothèque dans un processus dédié. Vous commencerez ce processus, transmettre des données et paramètres, exécutez le code bibliothèque, récupérer les résultats. Une fois que vous décidez de la consommation de mémoire n'est plus tolérable que vous redémarrez le processus.

Answer 2

En utilisant une bibliothèque qui n'est pas cassé serait probablement beaucoup plus facile, mais si vous pouvez essayer un ins't de remplacement disponibles intercepter les appels d'allocation. Si la bibliothèque est pas trop mal « optimisé » (en particulier la fonction inline) vous pouvez démonter et localiser le malloc et les fonctions libres; le chargement, vous pouvez remplacer tous les 4 (ou 8 sur p64 système) séquence d'octets qui code pour cette adresse avec un qui pointe vers votre propre allocateur de mémoire. Ceci est presque garanti d'être un buggy, TimeSink illisible, cependant, il ne faut pas le faire si vous pouvez trouver un remplaçant de travail.

Edit:

Saw @ réponse de Dentranchante, qui a une meilleure chance de travailler. Je conseille toujours d'essayer de trouver un remplaçant bien.

Answer 3

Vous devriez demander l'avis de Roman Lygin - il travaillait à occ. Il a au moins un poste qui mentionne la gestion de la mémoire http: // opencascade.blogspot.com/2009/06/developing-parallel-applications-with_23.html.

Si vous demandez gentiment, il pourrait même écrire un message qui explique les parties internes mmgt.