Ubuntu-fr

o0Zz

Malloc et noyau linux

Bonjour à tous,

Voici un petit code : (qui vaux mieux qu'un long discourt)
char * MyZone = (char*) malloc(1024);
for (int i=0;i<2048;i++)
{
    MyZone[i]=0;
}

Ce code ne va pas planter pourtant il devrait.
Ceci est due à une certaine tolérance du noyau qui alloue plus de mémoire virtuel que ce que l'on demande.

Ma question : Peut-on restreindre cette allocation pour qu'il n'alloue que le stricte minimum (c'est à dire 1024) afin qu'il nous retourne une erreur lorsqu'on essai d'accéder a MyZone[1024]

Y'a t'il possibilité de configurer ça à la compilation du noyau, ou dans un fichier de config ?

Je vous remercie d'avance de votre aide !

rniamo

Re : Malloc et noyau linux

ce code peut planter normalement, sauf si tu as de la chance. Essaye d'allouer plus gros t'en aura peut être moins. Je ne pense pas que ça se configure.

---

< Quelques un des mes programmes  | Cuisine Facile (pour les gourmands) | Fast MVC for PHP >
        \   ^__^
         \  (o o)\_______
            (___)\            )\

o0Zz

Re : Malloc et noyau linux

Oui ce code peu planter (je l'ai signalé) et non je n'ai pas de la chance et oui si j'alloue plus gros je pourrais aller moins loin mais si j'alloue beaucoup plus gros je pourrais aller Beaucoup plus loin car l'OS à des paliers j'ai l'impression.

Enfin bref j'aimerais avoir un confirmation que ce n'est pas possible ou une confirmation que c'est possible

Merci

Link31

Re : Malloc et noyau linux

echo 2 | sudo tee /proc/sys/vm/overcommit_memory

M'enfin, et la doc alors ? C'est dans le man malloc, section BUGS, impossible de le manquer.

edit : au passage, je te rappelle que la taille des pages sur x86 est de 4096 octets, tu ne pourras donc pas allouer seulement 1024 octets et espérer que le hardware te signale un (léger) dépassement de tampon. Pour ça, il y a par exemple la libmudflap de gcc, ou valgrind.

Dernière modification par Link31 (Le 19/11/2008, à 16:08)

philou8237

Re : Malloc et noyau linux

En fait le noyau ne sait allouer que 1 page mémoire minimum (donc 4096 octets).
Pour forcer le plantage tu as plusieurs possibilités
- l'option J de malloc (voir man, variable MALLOC_OPTION si je me souviens bien)
- la bibliothèque electric-fence (une fois installée, compile avec  -lefence), qui ajoute une surcouche à malloc et va te renvoyer une adresse correspondant à la fin de la mémoire allouée moins la taille de ta donnée. Si tu déborde de 1 octet.... c'est SEGV.
Sinon, effectivement, vallgrind va te le dire si tu dépasse.
Edit de Link31: tite faute de frappe : c'est 4096 octets pas ko

LittleJawa

Re : Malloc et noyau linux

Valgrind est l'outil que je te conseillerai en premier.
Il permet de vérifier pas mal de choses, et pas seulement le dépassement de buffer.
Il est un peu compliqué à utiliser et mettre en place, et bouffe pas mal de resources, donc c'est à utiliser en phase de développement/debug.

Perso, je l'utilise de temps en temps, mais pour le boulot de tout les jours, j'ai inclu mes propres routines d'allocation/désallocation qui font les vérifications adéquates (en claire : j'alloue toujours un poil plus de mémoire, et je met des valeurs fixe vérifiable autour du buffer que je renvoi à l'appelant, ce qui me permet ensuite de vérifier si ça a été corrompu ou pas).
C'est juste en mode "debug" (avec des directives de compil) et ça ne me donne pas l'endroit exact ou la corruption est apparue. Mais ça ne prend que très peu de CPU, et ça me permet de voir très vite qu'il y a un problème dans le code.
Ca me permet aussi de vérifier le nombre d'allocation/désallocation, et donc de détecter les fuites potentielles (là encore, affiner la recherche est plus compliquée, mais j'y arrive en gérant des tags dans le code pour savoir où les resources sont allouées).

En clair : il n'y a pas de solution miracle à ton problème. Vérifier la corruption des buffer prend du temps CPU, et donc ce n'est pas fait par défaut par le kernel. Si tu veux le faire, soit tu l'implémentes, soit tu utilises un outil genre Valgrind.

Link31

Re : Malloc et noyau linux

tite faute de frappe : c'est 4096 octets pas ko

En effet. Ça aurait fait des pages un peu trop grandes