PDFium memory leaks

Version imprimable

1 pièce(s) jointe(s)

PDFium memory leaks

Bonjour,

Je travaille sur une version modifiée de libPDFium qui exploite les derniers sources du projet PDFium...

et je rencontre un problème que je ne comprend pas, mais comme je ne maîtrise pas C++ je me demande si une explication simple est envisageable.

si je fais une boucle (sous Delphi mais qu'importe) de LoadLibrary/FreeLibrary sur la DLL sans faire aucun appel d'aucune sorte, j'ai la consommation mémoire de mon process qui augmente petit à petit...j'ai fait le test avec d'ancienne version de la DLL, ou avec une DLL vierge, je n'ai pas ce phénomène. Or la fonction DllMain est vide...alors qu'est ce qui peut bien allouer de la mémoire dans cette boucle ?!

voici l'occupation mémoire en mode debug sous VC++, chaque itération (j'en fait 1000) prend un peu de mémoire
Pièce jointe 561329

j'ai tenté de remonter les memoryleaks avec un code que j'ai trouvé je ne sais plus où, mais ça ne semble rien faire
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 #define MEM #ifdef MEM #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> #endif BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { //case DLL_PROCESS_ATTACH: //case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: #ifdef MEM _CrtDumpMemoryLeaks(); #endif break; } LOG("DLLMAIN\n") return TRUE; }
Merci

2 pièce(s) jointe(s)

alors là ! je suis de plus en plus perplexe !

voici un code C++
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #include <iostream> #include <windows.h> int main() { for (int i = 0; i < 1000; i++) { std::cout << i << "\n"; HMODULE h = LoadLibrary(L"libpdfium.dll"); FreeLibrary(h); } std::cout << "Done\n"; }
et la consommation mémoire à l'exécution
Pièce jointe 561374
et voici un code Delphi
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 program libTestDelphi; {$APPTYPE CONSOLE} {$R *.res} uses Winapi.Windows; var i: Integer; h: THandle; begin for i := 0 to 9999 do begin WriteLn(i); h := LoadLibrary('libpdfium.dll'); FreeLibrary(h); end; WriteLn('Done'); end.
et la consommation mémoire ?!
Pièce jointe 561378

même résultat avec C++Builder on TCC (Tiny C Compiler)...c'est donc un truc spécifique à VC++ ? ah...ou alors l'allocation étant de base plus grande (13Mb) on ne voit pas le grossissement ?! mais la courbe n'est tout de même pas la même.

Salut,

Le fait est que je ne comprend pas pourquoi tu t'amuses à charger / libérer la bibliothèque.

Généralement, l'utilisation d'une dll est de se dire qu'on la charge au début, qu'on la libère à la fin, si bien que, même si tu avais des milliers de pdf à génrer automatiquement, l'idée de base serait d'avoir un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 int main(){ /* initialisation: on charge libpdfium */ HMODULE h = LoadLibrary(L"libpdfium.dll"); /* exécution du programme */ generateAllPdfs(/* params */) /* finalisation et nettoyage */ FreeLibrary(h); } /* avec une fonction de generation des pdf qui pourrait prendre * la forme d'une boucle */ void generateAllPdfs(/* params */ ){ for(int i = 0; i< nombrePdfRequis; ++i){ /* ... */ } }

01/05/2020, 00h34
foetus

Citation:

Envoyé par koala01

on la charge au début, qu'on la libère à la fin, si bien que, même si tu avais des milliers de pdf à générer automatiquement

Et on n'a plus qu'à prendre les adresses des fonctions de cette bibliothèque :whistle: ... ce qui est le principal.

Ton code et celui de @koala01 ne gère pas les erreurs :whistle: - effectivement c'est le code qui sera exécuté dans 99% des cas.
Mais ici il n'y a pas d'erreurs (quoique :koi:), le problème peut venir d'1 problème indépendant du code - je pense à la gestion des "threads" Peut-être qu'avec Delphi, la destruction du "thread" est reportée, peut-être que Visual réutilise le "thread" (il détecte que c'est le même ou il utilise 1 bassin), ...

Ce genre de micro fuites mémoire, il faut la tester en mode "release" dans 1 environnement de production. En mode "debug" et/ ou avec du code fait en one-shot, ... c'est anecdotique - surtout lorsqu'on touche aux entrailles d'1 bibliothèque (WinAPI qui plus est :wow:)
02/05/2020, 01h28
Paul TOTH

alors, le problème de PDFium c'est qu'il n'est pas threadsafe...l'idée est donc de copier la DLL pour chaque Thread et charger la DLL qui possède un nom différent pour avoir une nouvelle copie du code qui tourne dans son propre Thread.

ça explique pourquoi il y a plusieurs chargements, par contre je suis bien d'accord avec toi, il ne sert à rien de charger/décharger des 100ènes de fois la DLL, mais dans le code qu'on m'a soumis, la DLL est chargée par le thread, déchargée en fin de traitement et tu peux potentiellement avec des 100ènes de thread qui se suivent au cours du temps.

ce que j'ai recommandé c'est de réutiliser les DLL chargées, car on n'a jamais des 100ènes de thread qui tournent à un instant T...mais le code de départ aurait du fonctionner sans cette fuite de mémoire que je ne m'explique pas.
03/05/2020, 03h06
koala01

Mais, à partir du moment où les choses sont dites et que la bibliothèque n'est pas thread safe, la question est: pourquoi voudrais tu que plusieurs threads n'aillent utiliser cette bibliothèque (sous entendu: en même temps) :question:

Car, l'un dans l'autre, la génération du pdf sera la toute dernière chose que tu voudras faire, après que toutes les manipulations de données aient été effectuées.

C'est sur la manipulation de tes données que l'utilisation de threads peut s'avérer utile, histoire que le traitement général des informations n'en vienne pas à demander des heures (ou pour qu'il en demande un peu moins) pour obtenir le résultat souhaité.

Mais la génération d'un pdf, ce n'est qu'une sauvegarde du résultat dans un format bien spécifique, et il n'y a donc aucune raison de commencer à sauvegarder les données tant... qu'elles sont encore en cours de modification.

Après, si tu as de nombreux pdf à générer -- parce qu'il n'y a que quelques données qui diffèrent mais que ces différences sont importantes, hé bien... c'est un temps "incompressible", et il est ** peut être ** intéressant d'avoir un (et un seul) thread qui génère les pdf à partir des données qui ne seront plus modifiées, pendant que "d'autres threads" seront occupés à préparer les prochaines données qui devront être enregistrées. Il n'empêche que ce sera toujours un seul et unique thread qui générera l'ensemble des fichiers pdf dont tu as besoin ;)
03/05/2020, 13h15
dalfab

Bonjour,

Une question est : est-ce que la dll consomme ou pas de la mémoire?

On voit que la mémoire consommée augmente d'environ 1MO sous C++ et d'environ 4MO sous Delphi. Ce qui indique une consommation d'environ 1MO/10000=100 octets par déchargement. Mais d'où viennent ces graphiques? Sous Delphi, il y a un garbage collector donc peut-être qu'il reste de la mémoire à libérer et que la consommation de mémoire ne serait qu'apparente. Mais sous C++, à condition de ne rien faire en même temps, on rend immédiatement la mémoire.
Il y a donc ici un doute sur la dll. Il suffit qu'elle fasse une allocation de mémoire globale qui ne serait pas libérée au moment du déchargement pour expliquer cette dérive. C'est même assez probable.
Le _CrtDumpMemoryLeaks() risque fort de ne pas voir cette mémoire perdue, car il ne peut contrôler que la mémoire locale (celle du heap qu'on alloue avec malloc() ou new). Je ne pense pas qu'il puisse détecter la mémoire partagée car par définition elle doit rester jusqu'à la fin du process lui-même. Voir gestion de mémoire partagée sous Windows.

Si des threads sont exécutés dans la dll, s'ajoute un risque que la bibliothèque rende mal ses allocations, et c'est un problème fréquent sous Windows. Mais ça n'est vraisemblablement pas le problème mis en évidence ici (car pas de threads lancés) mais serais-ce détecté par _CrtDumpMemoryLeaks()? Je ne le crois pas non plus car la bibliothèque doit peut-être libérer ses objets qu'après l'appel à DllMain( , DLL_THREAD_DETACH , ).
03/05/2020, 19h32
Paul TOTH

Citation:

Envoyé par koala01

Mais, à partir du moment où les choses sont dites et que la bibliothèque n'est pas thread safe, la question est: pourquoi voudrais tu que plusieurs threads n'aillent utiliser cette bibliothèque (sous entendu: en même temps) :question:

en fait je ne pose pas de question sur l'usage intelligent ou pas de la DLL, et vu que tu ne connais pas le cas d'usage tu dis bcp de bêtises, mais je ne t'en veux pas ;)

Citation:

Envoyé par dalfab

Bonjour,

Une question est : est-ce que la dll consomme ou pas de la mémoire?

la DLL n'est pas supposée faire quoi que ce soit vu que je me contente de la charger et de la décharger, et que la fonction DllMain ne fait rien !

en cas d'usage normal, j'invoque la fonction d'initialisation, mais dans ce test non.

Citation:

Envoyé par dalfab

On voit que la mémoire consommée augmente d'environ 1MO sous C++ et d'environ 4MO sous Delphi. Ce qui indique une consommation d'environ 1MO/10000=100 octets par déchargement. Mais d'où viennent ces graphiques?

ces graphiques viennent de la DLL sous Visual Studio quand je la debug en laçant un programme de test qui se content de la charger/décharger en boucle...c'est donc la mémoire de l'exe qui est lancé par Visual Studio pendant le debug.

j'ai testé avec l'appli compilée sous Delphi, le code C++ sous Visual Studio, et sous C++Builder et TCC...seul le code compilé sous VS provoque le second graphique.

Citation:

Envoyé par dalfab

Sous Delphi, il y a un garbage collector donc peut-être qu'il reste de la mémoire à libérer et que la consommation de mémoire ne serait qu'apparente. Mais sous C++, à condition de ne rien faire en même temps, on rend immédiatement la mémoire.

Non il n'y a pas de garbage collector sous Delphi :) et quand bien même il y en aurait un, il ne serait pas sollicité dans cette boucle qui n'alloue rien

Citation:

Envoyé par dalfab

Il y a donc ici un doute sur la dll. Il suffit qu'elle fasse une allocation de mémoire globale qui ne serait pas libérée au moment du déchargement pour expliquer cette dérive. C'est même assez probable.
Le _CrtDumpMemoryLeaks() risque fort de ne pas voir cette mémoire perdue, car il ne peut contrôler que la mémoire locale (celle du heap qu'on alloue avec malloc() ou new). Je ne pense pas qu'il puisse détecter la mémoire partagée car par définition elle doit rester jusqu'à la fin du process lui-même. Voir gestion de mémoire partagée sous Windows.

euh...la boucle ne fait aucune allocation, elle charge puis décharge la DLL, c'est tout...et le DllMain est vierge, donc à part si dans le runtime C++ il se passe des choses avant l'appel à DllMain, je ne vois pas ce qui pourrait allouer quoi que ce soit

Citation:

Envoyé par dalfab

Si des threads sont exécutés dans la dll, s'ajoute un risque que la bibliothèque rende mal ses allocations, et c'est un problème fréquent sous Windows. Mais ça n'est vraisemblablement pas le problème mis en évidence ici (car pas de threads lancés) mais serais-ce détecté par _CrtDumpMemoryLeaks()? Je ne le crois pas non plus car la bibliothèque doit peut-être libérer ses objets qu'après l'appel à DllMain( , DLL_THREAD_DETACH , ).

alors voilà, j'ai trouvé un vieux bug qui correspond au symptôme, mais il concerne la version 2008 ! ça me fait penser qu'il y a peut-être un truc malgré tout...mais quoi ?!
04/05/2020, 02h19
koala01

Citation:

Envoyé par Paul TOTH

en fait je ne pose pas de question sur l'usage intelligent ou pas de la DLL, et vu que tu ne connais pas le cas d'usage tu dis bcp de bêtises, mais je ne t'en veux pas ;)

Ben, je ne fais que reprendre tes propres paroles, vu que tu dis, dans la même phrase:

Citation:

alors, le problème de PDFium c'est qu'il n'est pas threadsafe(...)

et

Citation:

(...) est donc de copier la DLL pour chaque Thread

Pour moi, il n'y a pas trente si solutions pour interpréter ce que tu dis, même si je ne connais pas le cas d'usage: tu veux utiliser dans plusieurs thread une bibliothèque qui n'est, de toute évidence, pas prévue pour.

Tu peux l'exprimer sous n'importe quelle forme, le problème de base restera toujours le même, et reviendra à vouloir absolument utiliser des roues de skateboard pour équiper une formule un.

Quant à ton cas d'utilisation, j'en ai rien à foutre parce que, quelle que soit ta situation, elle va se réduire à deux possibilités:

A: tu as un grand nombre de données à manipuler pour générer un seul fichier pdf, et tu veux accélérer le traitement de ces données. Et, dans ce cas, la génération du fichier pdf ne pourra se faire qu'une fois que toutes les données auront été traitées.

ou B: Ton grand nombre de données à manipuler va servir à générer un grand nombre de fichiers pdfs différents. Et, dans ce cas, tu peux -- éventuellement -- envisager d'avoir un (et un seul, vu que la bibliothèque n'est pas threadsafe) thread auquel tu transmettra tous les paquets de données devant permettre la génération des pdfs (dans une liste d'attente, par exemple) mais qui ne pourra générer qu'un seul pdf à la fois.

On peut tourner les choses comme on veut, on peut vouloir remplir n'importe quel cas d'utilisation possible, tu ne sauras pas faire les choses autrement avec la bibliothèque que tu as choisie. Tout simplement.

De là à dire que c'est le choix de la bibliothèque qui est à remettre en question, il n'y a évidemment qu'un pas que je t'engagerais volontiers à franchir ;)

Cependant, pour pouvoir franchir ce pas, il faudra répondre à une question qui fâche: existe-t-il une bibliothèque adaptée à tes besoins qui soit threadsafe, et, si tel est le cas, veux-tu / peux tu envisager son utilisation :question:
05/05/2020, 01h21
Paul TOTH

Citation:

Envoyé par koala01

Mais, à partir du moment où les choses sont dites et que la bibliothèque n'est pas thread safe, la question est: pourquoi voudrais tu que plusieurs threads n'aillent utiliser cette bibliothèque (sous entendu: en même temps) :question:

alors quand tu as une DLL libPDFium.DLL qui n'est pas threadsafe, tu ne peux l'utiliser que dans un seul thread....
MAIS si tu la recopies dans libPDFium1.DLL, tu peux la charger en mémoire "à côté"de la première, et utiliser cette copie dans un autre thread sans problème....exactement comme si c'était une DLL complètement différente...vu que LoadLibrary se base sur le nom de fichier, tu ne peux charger deux instances différentes de la même DLL qu'en faisant une copie du fichier avant.

Citation:

Envoyé par koala01

Car, l'un dans l'autre, la génération du pdf sera la toute dernière chose que tu voudras faire, après que toutes les manipulations de données aient été effectuées.

je ne génère pas de PDF, je me sert de PDFium pour extraire le texte de quelques milliers de PDF afin de soumettre ces textes à Elasticsearch.

Citation:

Envoyé par koala01

C'est sur la manipulation de tes données que l'utilisation de threads peut s'avérer utile, histoire que le traitement général des informations n'en vienne pas à demander des heures (ou pour qu'il en demande un peu moins) pour obtenir le résultat souhaité.

Mais la génération d'un pdf, ce n'est qu'une sauvegarde du résultat dans un format bien spécifique, et il n'y a donc aucune raison de commencer à sauvegarder les données tant... qu'elles sont encore en cours de modification.

là tu parles dans le vide en prétendant savoir mieux que moi ce que je dois faire alors que tu ne sais pas quelle tâche je fais...enfin maintenant si, mais elle n'a simplement rien à avoir avec ce que tu présupposais ... et elle n'a de toute façon aucun rapport avec le problème posé.

Citation:

Envoyé par koala01

Après, si tu as de nombreux pdf à générer -- parce qu'il n'y a que quelques données qui diffèrent mais que ces différences sont importantes, hé bien... c'est un temps "incompressible", et il est ** peut être ** intéressant d'avoir un (et un seul) thread qui génère les pdf à partir des données qui ne seront plus modifiées, pendant que "d'autres threads" seront occupés à préparer les prochaines données qui devront être enregistrées. Il n'empêche que ce sera toujours un seul et unique thread qui générera l'ensemble des fichiers pdf dont tu as besoin ;)

nope

et donc à part m'expliquer comment je devrais travailler, tu ne m'avances pas bcp sur la compréhension de cette fuite mémoire. Comme expliqué plus haut, le problème d'usage de la DLL est résolu depuis longtemps, mais je n'aime pas résoudre un problème non identifié, c'est intellectuellement insatisfaisant, et ... dans le cas présent j'en doute...mais parfois cela te remonte à la figure plus tard car tu n'as fait que masquer le problème sans le résoudre.