Discussion :

[r2d2abc]

Bonjour à tous, j'ai un petit soucis épineux et aimerais votre avis.
J'ai une application qui utilise une dll buggée (avec un mem leak régulier sans les sources).
Actuellemnt je reboot le process serveur (service dont j'ai les sources) qui l'utilise toutes les nuits mais ca me chauffe un peu comme 1° technique.
Je voudrais pouvoir surveiller la consommation de cette dll et passé un certain cap la décharger/recharger.
J'ai utilisé un projet de test avec un dll qui simule la fuite mais toutes les fonctions que j'ai trouvées dans le msdn ne me permettent pas de n'avoir llocaliser la consommation mémoire par dlln c tjrs au niveau du processus.
Any suggestions ..

[Jenna]

C'est normal, la mémoire appartient au processus, pas à la DLL

Donc à la limite, tu peux surveiller ton process et le tuer s'il déraille.

Par contre décharger et recharger une DLL, cela me parait un peux dangereux comme méthode.

[r2d2abc]

décharger / recharger se font très facilement (même en env multith comme c la cas, je ne pratique que comme cela d'ailleurs), mais c le fait que la dll soit mappée dans la plage du processus qui rend justement la question épineuse ..
peut être une possibilité en dumpant la mémoire du processus et forcant le chargement de la dll à une adresse pour limiter le calcul à partir de là ...
continue searching ...
mais merci de ta suggestion

[Médinoc]

Décharger la DLL ne libèrera pas la mémoire qu'elle aura allouée sur le tas du processus, à moins que la DLL ne contienne du code de nettoyage pour ça.

[r2d2abc]

certes d'où le soucis de mieux cerner ce qui est consommé, arrêter / relancer le process serveur juste pour une dll me trouble,
ou alors déporter le code dans un process annexe et communiquer avec lui en le surveillant, je cherche cherche la meilleure solution ...
il faut mieux comprendre où cela se passe, me tourne vers les fonctions non documentées ou les autres ..
merci

[r2d2abc]

en fait même si la dll est chargée dans l'espace du processus appelant, elle possède son propre système de gestion de la mémoire, et le fait de la décharger libère la mémoire allouée.
flagrant avec plusieurs compilo (vc/vs8/borland..) même résultat
il ne reste plus qu'à tester ...
code dll

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <windows.h>
#include <iostream.h>
#define _EXPORTDLL
#include "dll.h"

#define null  NULL
#define dword DWORD
BOOL APIENTRY DllMain (HINSTANCE hInst,     // Library instance handle. 
                       DWORD reason,       	//Reason this function is being called
                       LPVOID reserved)		// Not used    
{
	switch (reason)
	{
		case DLL_PROCESS_ATTACH:
		break;

		case DLL_PROCESS_DETACH:
		break;

		case DLL_THREAD_ATTACH:
		break;

		case DLL_THREAD_DETACH:
		break;
	}

	// Returns TRUE on success, FALSE on failure 
	return TRUE;
}

/*
LIBRARY     DLL.DLL

EXPORTS
    @__lockDebuggerData$qv         @2   ; __lockDebuggerData()
    @__unlockDebuggerData$qv       @3   ; __unlockDebuggerData()
    ___CPPdebugHook                @4   
    _testleak                      @1   
*/    

DWORD WINAPI InstanceThread(LPVOID lpvParam);

DLLEXPORT HANDLE testleakmem (HINSTANCE h)
{
  DWORD  dwThreadId; 
  HANDLE hThread;
	 
  hThread = CreateThread( 
            NULL,              // no security attribute 
            0,                 // default stack size 
            InstanceThread,    // thread proc
            NULL,    // thread parameter 
            0,                 // not suspended 
            &dwThreadId);
            
  return hThread;          
}
												
DWORD WINAPI InstanceThread(LPVOID lpvParam) 
{
 cout<<endl<<"thread:in";
 int z=0;
 dword t0=GetTickCount ();
				
 while (1) 
  { 
    //cout<<endl<<z++; 
    Sleep(0);
    new int[1000]; //*********** MEM LEAK
    if (GetTickCount()-t0<5000) continue;
    break;
  }
 cout<<endl<<"thread:out";
}

code caller

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
int main(int argc, char *argv[])
{
  HMODULE g_hmodule=GetModuleHandle(NULL); //null=this module
  HINSTANCE g_hinstance=(HINSTANCE)g_hmodule;


  MemStatus ();
  
  if (MountLibrary())
    {
       //ListProcess();
       hp=GetCurrentProcess();      //handle
       pid=GetCurrentProcessId();   //pid
       
       //MemStatus ();
       MemStatusEx ();
       HeapDump();
       PrintProcessNameAndID (pid);
       PrintMemoryInfo (pid);
       PrintModules (pid);
       
       GetProcessList(pid);
       //Sleep (60000);
       
       //OK from dll to pipo() function
       cout<<endl<<"library mounted";
       testleak=(pfntestleak)GetProcAddress (hdll, "_testleak");
       if (testleak)
         {
           testleak(g_hinstance); //OK
         }
         
        UnmountLibrary();
        cout<<"\nlibrary dismounted";
    }


   //loop which external function
   while (1)
     {
       if (!MountLibrary()) break;
         
       cout<<"\nlibrary mounted";
       testleakmem=(pfntestleakmem)GetProcAddress (hdll, "_testleakmem");
       if (testleakmem) 
        {
           HANDLE hth=testleakmem (g_hinstance);
           cout<<endl<<"-------------------------------------";
           WaitForSingleObject (hth,INFINITE);
           CloseHandle (hth);
           cout<<endl<<"+++++++++++++++++++++++++++++++++++++";
        }
          
       UnmountLibrary(); // processus mem returns at bottom
       cout<<"\nlibrary dismounted, wait ...";
       Sleep (5000);
     }

  return 0;
}

[Médinoc]

Avec la CRT dynamique? Vachement surprenant.

[r2d2abc]

merci à tous ceux qui ont pris le temps de me répondre

[bacelar]

Si vous ne voulez pas corriger le problème de cette dll (réfléchissez-y quand même), le plus simple est de la charger dans un exécutable dédié et de lui demander (à l'exécutable) de se terminer au lieu de décharger la dll.

[Médinoc]

Si vous ne voulez pas corriger le problème de cette dll (réfléchissez-y quand même).

Je rappelle que r2d2abc a dit dans son premier message qu'il n'avait pas les sources.

[bacelar]

reverse-engineering.

[r2d2abc]

aaaaah le fameux reverse engineering que ne ferions/serions pas sans lui ...

[r2d2abc]

certes bacelar mais comment ce process dédié pourrait il communiquer/échanger des structures, ^, etc.. and co avec le process "maître" serveur tout en restant aussi performant qu'un appel call/jmp linké sur les fonctions de la dll même si les moyens ne manquent pas (ipc....) ?

[bacelar]

On ne peut pas avoir le beurre et l'argent du beurre.
Il existe de nombreux IPC, il faut prendre celui qui serait le plus simple avec des performances acceptables. Sur le papier, la mémoire mappé devrait être la plus rapide mais je serais plus sur une approche utilisant un serveur de composant COM out-of-process. Cela permettra toujours d'avoir la même sémantique d'appel de fonctions.
Voir du surrogate de composant COM en dll.

[r2d2abc]

thank's bacelar, il n'y a pas de miracles donc
merci pour tes propos

[Obsidian]

thank's bacelar, il n'y a pas de miracles donc
merci pour tes propos

Juste pour savoir, c'est quelle DLL ? Ou quel genre ? Peut-être peux-tu trouver une autre bibliothèque approchée et faire les adaptations nécessaires…

Sinon, tu peux essayer de tracer les appels systèmes faits par le code de ta bibliothèque. Peut-être trouveras-tu dans leurs arguments les combinaisons de valeurs qui la font bugger, et les contourner.