[VC++/ASM] Allocation dynamique de mémoire ?

Bonjour,

Dans le cadre d'un jeu réalisé par des amis, j'ai réalisé une petite DLL de cryptage/decryptage de fichiers en C++ sous VC++. Pour en optimiser les performances, j'ai convertit la partie la plus critique de l'agorithme en assembleur, avec un gain de temps impressionnant. Cependant j'aimerais maintenant convertir le reste du code en assembleur sous MASM32 (en fait c'est surtout que mes amis me demandent une DLL aussi petite que possible).

Et là où je bloque, c'est sur la façon de réaliser les allocations dynamiques de mémoire. J'y ai passé plusieurs jours sans y parvenir.

J'ai tenté d'utiliser HeapAlloc et VirutalAlloc sans grand succès. Au premier appel de la fonction, tout fonctionne parfaitement, mais dès le second appel, le programme plante avec une erreur de violation d'accès. A des fins de tests, j'ai alors fait une fonction inutile qui se contente d'appeler HeapAlloc, d'écrire dans le premier octet du buffer ainsi alloué, puis de libérer le buffer avec HeapFree. Je me suis retrouvé avec le même problème, à savoir que le premier appel fonctionnait, mais pas les suivants. Pourtant, HeapAlloc ne me retourne pas d'erreur.

Je précise que je ne suis pas encore passé sous MASM32.

Ma question est donc dans un premier temps: quelle est la façon correcte de faire une allocation dynamique de mémoire en assembleur ?

Si par la suite je n'y arrive toujours pas, je posterai le code de la fonction.

En vous remerciant par avance pour vos réponses.

Hello,

Si vous passez par VirtualAlloc, vérifiez bien que votre mapping et en Read_write si jamais vous essayez d'y écrire :

Code:

---

1 2	invoke VirtualAlloc,NULL,SizeBuffer,MEM_COMMIT,PAGE_READWRITE

---

Sinon pour le fond du problème je ve vois pas trop...surement un problème dans votre code. Un petit copier/coller serait peut être utile.

Cordialement, Neitsa.

Merci beaucoup pour votre réponse.

En fait, comme je suis encore sous VC++ et pas encore passé à MASM32, j'appelle les fonctions de cette façon:

Pour allouer la mémoire:

Code:

---

1 2 3 4 5 6

push PAGE_READWRITE push MEM_RESERVE | MEM_COMMIT push FSize push NULL call dword ptr VirtualAlloc mov Buffer, eax

---

Pour libérer la mémoire:

Code:

---

1 2 3 4

push MEM_RELEASE push FSize push Buffer call dword ptr VirtualFree

---

Mes variables sont déclarées façon C:

Code:

---

1 2	char *Buffer; int FSize;

---

Voilà, une fonction ne contenant que ces éléments plante si j'essaie de mettre quelques chose dans le Buffer lors d'un deuxième appel, mais fonctionne lors du premier appel.

D'ailleurs, voici comment je procède pour accéder au Buffer ainsi obtenu:

Code:

---

1 2	mov edi, Buffer mov [edi], al

---

Ensuite j'incrémente edi pour accéder au reste du buffer. Mais même sans l'incrémenter, au deuxième appel, ça plante.

Hello,

je suis étonné que même le premier appel puisse fonctionner:

Code:

---

1 2 3 4 5 6 7

push PAGE_READWRITE push MEM_RESERVE | MEM_COMMIT ; impossible ! push FSize push NULL call dword ptr VirtualAlloc mov Buffer, eax

---

les paramètres RESERVE et COMMIT sont incompatibles entre eux.

RESERVE, comme son nom l'indique ne fait que réserver un bloc mémoire sans l'allouer, de ce fait le bloc ne pourra être pris par une autre fonction ou une réallocation de mémoire.

COMMIT alloue un bloc (de ce fait il est réservé) en mémoire, ainsi on peut alors s'en servir, le bloc reserver ne servant à rien en tant que tel.

c'est bien préciser dans la MSDN

Citation:

---

flAllocationType
[in] Type of memory allocation. This parameter must contain one of the following values.

---

A part ce détail je ne vois pas ce qui cloche, le bout de code me semble correct...

Si vous avez d'autres problèmes n'hésitez pas. Sinon il reste toujours l'option du débugging de l'application.(au cas où je peux toujours vous aider).

Cordialement, Neitsa.

Et bien, je pensais qu'il fallait réserver la mémoire avant de l'allouer. Alors si on utilise MEM_COMMIT, la mémoire est réservée et allouée ? Ou faut-il faire deux appels ?

EDIT: J'ai été plus sage, j'ai vérifié que MEM_COMMIT seul marchait.

Voici donc mon code actuel:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

push PAGE_READWRITE push MEM_COMMIT push FSize push NULL call dword ptr VirtualAlloc mov Buffer, eax   mov edi, Buffer mov al, [edi]   push MEM_RELEASE push NULL push Buffer call dword ptr VirtualFree

---

Je précise que c'est juste ma fonction de test. Comme à son habitude, elle fonctionne au premier appel, mais au second appel, j'ai un message de violation d'accès sur "mov al, [edi]".

Pourquoi ne pas utiliser la fonction standard malloc ?

Hello,

Pour le MEM_COMMIT c'est bien ca.

un petit problème encore

Code:

---

1 2 3

mov edi, Buffer mov al, [edi] ; c'est plutôt l'inverse

---

on devrais plutôt faire ceci:

Code:

---

1 2 3

mov edi, Buffer mov byte ptr [edi] ,al

---

(avec en plus une indication de format).

Citation:

---

Envoyé par Selenite

Pourquoi ne pas utiliser la fonction standard malloc ?

---

Eh bien parce que cette fonction appartient au standard C, et que le but du jeu est de convertir tout en asm.

Cela dit, il est effectivement dommage de vouloir écrire tout en asm si ce n'est que pour une contrainte de taille. J'en ai pas à vous conseiller, mais vous pourriez plutôt rechercher les compilateurs qui sont capable de produire un obj petit. Ca existe, et ce serait une méthode certainement plus rapide, à moins que vous n'ayez qu'une petite vingtaine de lignes à convertir.


En ce qui concerne le mov [edi], je ne pense pas qu'il y ait d'erreur. Le programme testait la lecture et non l'écriture, aucun contenu explicite qui justifie l'écriture dans al, bref, ca ne risque pas de changer grand chose.


Si vous avez une violation d'accès, vous devriez avoir l'adresse qu'on a tenté de lire/écrire. Et si vous êtes sur VC, vous devriez pouvoir vérifier la valeur retournée par VirtualAlloc, que par ailleurs, il faudrait toujours vérifier dans le code. A priori, je ne vois pas ce qui puisse justifier qu'un deuxième appel ne fonctionne pas, si bien entendu, les paramètres d'appel n'ont pas changé. Mais il faut savoir que sous windows, et en particulier quand on commence à faire de l'asm, une erreur à l'opposée du code qui plante dans le programme peut créer ce genre d'erreur.


Enfin, notez, qu'il nétait pas indispensable d'utiliser VirtualAlloc. Vous pouviez très bien utiliser la fonction plus générale GlobalAlloc, qui permet de se préoccuper de moins de détails, mais enfin, ca ne résoud pas le problème.


Donc, puisqu'on est pas très doués apparement, donnez nous un peu plus d'informations sur la violation d'accès.



Amicalement, Blustuff.