Discussion :

[devconf77]

Bonjour,
Je remarque dans le gestionnaire de tâches de windows que la mémoire utilisée par une de mes applications windows, augmente sensiblement. Mise à part les opérateurs "new" et "malloc" qui peuvent faire augmenter l'utilisation mémoire, y-a-t-il d'autres opérations qui pourraient produire les mêmes effets?
Merci d'avance
Devconf77

[Médinoc]

Eh bien, tout ce qui crée quelque chose consomme de la mémoire. Y compris les ressources USER et GDI...

[Mat.M]

Bonjour,
utilisée par une de mes applications windows, augmente sensiblement. Mise à part les opérateurs "new" et "malloc" qui peuvent faire augmenter l'utilisation mémoire, y-a-t-il d'autres opérations qui pourraient produire les mêmes effets?
Merci d'avance
Devconf77

Avec quoi sont développées les applications en question ?
Il y a aussi les API Windows comme GlobalAlloc HeapAlloc etc..

[devconf77]

J'ai une autre application où il y a des Heapalloc, qui présente également des fuites. Mais l'application que je traite en ce momment ne contient ni GlobalAlloc et ni HeapAlloc. elle Contient des fonctions SnmpMgrRequest, Openprocess, TerminateProcess, OpenService, StartService. Bref des fonctions pour envoyer des requêtes SNMP, pour gérer des processus et des services windows. J'ai remarqué après quelques mesures de consommation de mémoire autour de la fonction SnmpMgrRequest que cette dernière me prend de temps en temps 4ko sans jamais les rendre. Je ne sais pas comment régler ces problèmes de fuite.
Merci d'avance pour toute aide
devconf77

[devconf77]

PS : Les applications sont développées avec visual c++ 6
devconf77

[Vincent Rogier]

La plupart des API qui retournent un handle allouent de la mémoire pour le handle.. Et donc un oubli de libération d'un handle (un CloseHandle() par exemple) peut à la longue être couteux...

Donc vérifier que tous les appels retournant des handles sont toujours suivis par des libérations..

Par exemple, OpenService() nécessite deux handles (un pour le manager un pour le service). Si ces deux handles ne sont pas fermés, il y a fuite mémoire...

Donc revois ton code et tu trouveras les appels manquants

[d'Oursse]

tu peux utiliser mpatrol pour savoir ou se trouve ta fuite memoire

[devconf77]

A l'attention de vicenzo,
A la suite d'un open..., je fais bien un CloseHandle. Donc le problème ne vient pas de là à mon avis.
defconf77

[Vincent Rogier]

... Pourtant il y a bien une fuite... Et elle est forcement dans ton code.

Utilise tu des librairies tierces ? (autres que win32)

si besoin, je peux parcourir ton code afin de voir si y a pas une coquille quelque part..

[devconf77]

Effectivement, j'utilise une librairie tierce (autre que win32). Je vais enlever les appels de fonctions de cette librairie et tester mon application
Merci
Devconf77

[devconf77]

Voici un exemple d'appel de fonctions de l'api qui produisent des fuites de mémoire. Tu peux créer un projet console sous visual c++6, le compiler et l'exécuter. Ce petit programme obtient la taille mémoire utilisée par explorer.exe et l'affiche. Tu peux remplacer explorer.exe dans le source par une autre appli qui figure dans ton gestionnaire de tâches. Dans ce cas il faut aussi remplacer le chemin de explorer.exe par le chemin de l'appli que tu as choisie.

#include <windows.h>
#include <psapi.h>
#include <stdio.h>

void main()
{
char sProcName[MAX_PATH];
strcpy(sProcName,"c:\\windows\\explorer.exe");
strcpy(sProcName,"d:\\Program Files\\TDF\\SmipWatch\\SmipWatch.exe");

DWORD aProcesses[1024], cbNeeded, cProcesses;
unsigned int i;
HANDLE hProcess;
HMODULE hMod;
PROCESS_MEMORY_COUNTERS pmc;
char sFileName[MAX_PATH];
DWORD dwSize;

// Isole le nom de l'exécutable sans chemin
char sProcess[MAX_PATH];
strcpy(sProcess, sProcName);
char *pAntiSlash = strrchr(sProcName,'\\');
if(pAntiSlash)
{
pAntiSlash += 1;
strcpy(sProcess,pAntiSlash);
}
for(i = 0; i < strlen(sProcess); i++)
{
sProcess[i] = tolower(sProcess[i]);
}

int intCount = 0;

while(1)
{
// Get the list of process identifiers.
if ( !EnumProcesses( aProcesses, sizeof(aProcesses), &cbNeeded ) )
return;

// Calculate how many process identifiers were returned.
cProcesses = cbNeeded / sizeof(DWORD);

for ( i = 0; i < cProcesses; i++ )
{
// Get information about the process.
hProcess = OpenProcess( PROCESS_QUERY_INFORMATION |
PROCESS_VM_READ,
FALSE, aProcesses[i] );
if (hProcess)
{
if (EnumProcessModules(hProcess, &hMod, sizeof(hMod), &dwSize))
{
// Get the module name
if (GetModuleBaseName(hProcess, hMod, sFileName, MAX_PATH))
{
for(int j = 0; (size_t)j < strlen(sFileName); j++)
{
sFileName[j] = tolower(sFileName[j]);
}

if(strcmp(sFileName,sProcess) == 0)
{
// Get memory info
if ( GetProcessMemoryInfo(hProcess, &pmc, sizeof(pmc)))
{
intCount++;
printf("%d-Memoire utilisee par %s = %u\n",intCount,sFileName,pmc.WorkingSetSize);
}
}
}
}
CloseHandle( hProcess );
}//End if
}//End for
Sleep(2000);
}//End while

return;
}

[devconf77]

Dans le message précédent, il faut SUPPRIMER l'instruction : strcpy(sProcName,"d:\\Program Files\\TDF\\SmipWatch\\SmipWatch.exe");
Merci

[Vincent Rogier]

Bon, j'ai testé ton code (tiré de la msdn, si je ne m'abuse...) et sous ma config (VISTA / VS2005) j'ai effectué 17 000 itérations (toutes les 10 ms soit avec ta boucle de départ l'equivalent de 944 heures de ta boucle et pas un seul souci de mémoire....

C'est quoi ta config ?

PS : les deux boucles avec un strlen à chaque tour boucle pour tester la onguer de la variable qui ne change pas... inutile, perte de temps et a éviter !!!!!!