Euh, oui, il y avait des fuites de mémoire dans le bridge NPRuntime jusqu'à la version 1.1.6. Je ne sais pas si c'est ton problème en particulier, mais c'est ce que j'avais remarqué lors de ma phase de review du code.
Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.
Par exemple:$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee l
Ca fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?
[^] # Re: mem leak
Posté par Gwenole Beauchesne . En réponse à la dépêche nspluginwrapper 1.2.0. Évalué à 9.
Si tu suspectes encore des fuites de mémoire dans la version 1.2.0, il est également possible de ne lancer valgrind que sur nspluginwrapper, et donc les plug-ins, i.e. on ne s'embête pas à valgrind'er sur tout le browser. Pour ce faire, démarre juste le browser en le préfixant de la variable NPW_USE_VALGRIND=yes.
Par exemple:
$ NPW_USE_VALGRIND=yes NPW_VALGRIND_OPTIONS="--leak-check=full" firefox file:///path/to/file.pdf 2>&1|tee lCa fait un peu fonctionnalité secrète mais a priori ce n'était utile que pour moi. ;-) Ah oui, si tu vois une tripotée de variables utilisées avant d'être initialisées, t'en fais pas, c'est "normal" pour les plug-ins d'Adobe, ou bien est-ce valgrind qui ne détecte pas bien ces cas?