Discussion :

[BigzYeah]

Bien le bonjour !

Je viens de remarquer que l'utilisation d'embedding python dans une appli C++, donc en utilisant Py_Initialize() en début d'embedding et Py_Finalize() en fin dégageait une importante fuite mémoire.

J'ai vu sur le net des articles indiquant qu'aucun fixe n'existait et qu'il fallait faire avec. Outre le fait que je trouve ça complètement inacceptable et absolument pas professionnel, je voulais savoir si certains avaient plus d'info à ce sujet et surtout si le problème persiste sur la dernière version de Python en 3.1.2 (j'utilise la 2.7).

Merci à vous =)

[wiztricks]

Salut,

cut&paste du Python/C API Reference Manual de 3.1.2

void Py_Finalize()¶

Undo all initializations made by Py_Initialize() and subsequent use of Python/C API functions, and destroy all sub-interpreters (see Py_NewInterpreter() below) that were created and not yet destroyed since the last call to Py_Initialize(). Ideally, this frees all memory allocated by the Python interpreter. This is a no-op when called for a second time (without calling Py_Initialize() again first). There is no return value; errors during finalization are ignored.

This function is provided for a number of reasons. An embedding application might want to restart Python without having to restart the application itself. An application that has loaded the Python interpreter from a dynamically loadable library (or DLL) might want to free all memory allocated by Python before unloading the DLL. During a hunt for memory leaks in an application a developer might want to free all memory allocated by Python before exiting from the application.

Bugs and caveats: The destruction of modules and objects in modules is done in random order; this may cause destructors (__del__() methods) to fail when they depend on other objects (even functions) or modules. Dynamically loaded extension modules loaded by Python are not unloaded. Small amounts of memory allocated by the Python interpreter may not be freed (if you find a leak, please report it). Memory tied up in circular references between objects is not freed. Some memory allocated by extension modules may not be freed. Some extensions may not work properly if their initialization routine is called more than once; this can happen if an application calls Py_Initialize() and Py_Finalize() more than once.

Le problème persiste... et s'il est encore là c'est que sa correction n'est pas simple et/ou que sachant cela, les développeurs qui ont besoin de lancer un interpréteur Python depuis un code C trouvent facilement des solutions palliatives:
1 - on évite de le lancer plusieurs fois,
2 - on lance l'interpréteur dans un process séparé

Je comprends votre frustration mais ce sont des réalités et les réalités sont têtues.
- W

[BigzYeah]

C'est en effet quelque chose que j'avais déjà lu. A vrai dire ces derniers jours, j'ai lu une bonne dose de ref Python

Après certes, le lancer une fois n'est pas un problème, mais une fuite mémoire en est toujours un, quoi qu'il en soit, et dans un projet professionnel, c'est embêtant.

Le fait de lancer l'interpréteur dans un process séparé, avec Py_NewInterpreter() par exemple ne règle absolument pas le problème, il se reproduit juste sur un autre processus.

Le but de ce topic était plus d'avoir des bribes d'info, voire des légendes urbaines qui auraient pu mener à quelque chose. Mais j'ai bien peur que je vais devoir me coltiner ce fâcheux problème.

Néanmoins, merci de ta réponse =)

[wiztricks]

Le fait de lancer l'interpréteur dans un process séparé, avec Py_NewInterpreter() par exemple ne règle absolument pas le problème, il se reproduit juste sur un autre processus.

Py_NewInterpreter() est plus adapté pour la création de plusieurs instances de l'interpréteur dans un même process.

Un process séparé signifie 1 instance de l'interpréteur dans son propre process. Ce qui signifie un seul appel à Py_Finalize à la mort de ce process. Pour autant qu'on souhaite toujours lancer l'interpréteur ainsi - passer par des process séparé ouvre aussi d'autres options.

Après certes, le lancer une fois n'est pas un problème, mais une fuite mémoire en est toujours un, quoi qu'il en soit, et dans un projet professionnel, c'est embêtant.

Le propre du "professionnel" est de construire des solutions adaptées.
Cela suppose de bien connaître les avantages et les inconvénients des API/bibliothèques/modules qu'on va mettre en oeuvre.

Le but de ce topic était plus d'avoir des bribes d'info, voire des légendes urbaines qui auraient pu mener à quelque chose. Mais j'ai bien peur que je vais devoir me coltiner ce fâcheux problème.

Si vous avez besoin de lancer N*fois un interpréteur Python, vous savez maintenant ce que çà coûte de le faire avec la méthode que vous aviez initialement trouvée.
Suivant l'application que vous voulez réaliser, elle n'est pas nécessairement à jeter juste à utiliser avec précautions si vous êtes dans les cas mentionnées dans la documentation.
C'est pas compliqué...
Mais les réalités sont bien moins sexy que les légendes urbaines.
- W