Discussion :

[Paul TOTH]

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


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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Paul TOTH]

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

voici un code C++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

et voici un code Delphi

Code Delphi :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?!


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.

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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){
        /* ... */
    }
}

[foetus]

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 ... ce qui est le principal.

Ton code et celui de @koala01 ne gère pas les erreurs - effectivement c'est le code qui sera exécuté dans 99% des cas.
Mais ici il n'y a pas d'erreurs (quoique ), 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 )

[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.

[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)

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

[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 , ).

[Paul TOTH]

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)

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

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.

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.

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

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

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 ?!

[koala01]

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:

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

et

(...) 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

[Paul TOTH]

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)

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.

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.

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é.

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.