Malloc (Peut on configurer la flexibilité de l'OS)

cs_Booster Messages postés 235 Date d'inscription mercredi 30 octobre 2002 Statut Membre Dernière intervention 6 octobre 2009 - 18 nov. 2008 à 19:49
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019 - 19 nov. 2008 à 09:13
Bonjour à tous,

(Un petit code 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 (selon les OS) pourtant il devrait.
Ceci est due à une certaine flexibilité 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 !

6 réponses

cs_Booster Messages postés 235 Date d'inscription mercredi 30 octobre 2002 Statut Membre Dernière intervention 6 octobre 2009
18 nov. 2008 à 19:59
Je me suis mal exprimé quand je dit flexibilité le mot tolérant est plus adéquate de plus si vous connaissez une autre méthode que de modifier le noyau et sa configuration (comme une fonction c++) je suis aussi preneur :)

Merci d'avance.
0
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
18 nov. 2008 à 20:24
La rigueur du développeur ne serait pas suffisante ?

ciao...
BruNews, MVP VC++
0
cs_Booster Messages postés 235 Date d'inscription mercredi 30 octobre 2002 Statut Membre Dernière intervention 6 octobre 2009
18 nov. 2008 à 20:35
:) Certainement mais j'aimerais réellement faire cette expérience (si cela est possible).

De plus, ce type de configuration permet de vérifier que votre programme ne plantera pas un jour sans raisons.
(Car même le développeur le plus rigoureux à déjà eu ce genre de problèmes (Sur 3 lignes ont voit l'erreur mais sur 10 000 c'est moins évident)

Il y à bien des softs du type valgrind qui aide le développeurs (Pour les leaks en particulier) mais ceci serait une vrai aide suplémentaire.

Si quelqu'un connai un moyen, je suis toujours preneur.

Merci.
0
julienbj Messages postés 452 Date d'inscription jeudi 4 décembre 2003 Statut Membre Dernière intervention 19 décembre 2008 15
18 nov. 2008 à 22:08
Salut,

Je suis surpris de tes dire. Il me semble que ceci arrive quand tu développes en mode debug.
Il me semblait qu'en mode release, un plantage était quasi assuré.
Mais je dis peut être des bêtises...
Après tests, sous VS2008 en mode release, plantage du programme à cause de mémoire corrompu, mais cela dépend de ce que tu as comme données derrière....
En mode debug, plantage lors du free sur le buffer.

Dans le cas ou je me trompe:
J'ai développé une mini lib d'allocation dynamique qui "remplace" malloc, calloc, free, realloc et strdup.
Lorsque tu l'utilises en mode debug, elle t'indique une erreur si tu essaies de libérer un bloc mémoire corrompu (tu as écris avant ou après la taille que tu as alloué), et elle t'indique également les blocs non libérés lorsque tu fermes la librairie. Si elle n'est pas configurée en mode debug, elle n'ajoute presque rien à une utilisation lambda de malloc&co.
Si ça t'intéresse, je peux mettre cette lib sur cppfrance. Je me suis inspiré d'un des codes de JCDjcd. J'avais trouvé l'idée intéressante, je l'ai reprise à mes fins en l'adaptant à mes besoins.

--Vive le CSavon
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
19 nov. 2008 à 03:41
salut

sous gcc, en compilant avec l'option -g, et en lancant ton programme avec valgrind, il te liste les erreurs (et t'insulte quand t'as fait une betise :) )

brunews :
max@max-desktop:~$ valgrind konqueror

[...]

6973==
6973== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 336 from 4)
6973== malloc/free: in use at exit: 1,491,952 bytes in 7,825 blocks.
6973== malloc/free: 427,662 allocs, 419,837 frees, 90,934,292 bytes allocated.
6973== For counts of detected errors, rerun with: -v
6973== searching for pointers to 7,825 not-freed blocks.
6973== checked 2,444,152 bytes.
6973==
6973== LEAK SUMMARY:
6973==    definitely lost: 8,512 bytes in 171 blocks.
6973==      possibly lost: 32 bytes in 1 blocks.
6973==    still reachable: 1,483,408 bytes in 7,653 blocks.
6973==         suppressed: 0 bytes in 0 blocks.
6973== Rerun with --leak-check=full to see details of leaked memory.

et je ne suis pas sous debian testing, mais sous ubuntu stable.
0
BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
19 nov. 2008 à 09:13
Windows ONLY:
julienbj
malloc() est un appel HeapAlloc() sur GetProcessHeap() en mode sérialisé.
Mode debug ou release n'entre pour rien dans l'affaire, c'est une question de taille de page mémoire, 4 Ko.
Si donc on appelle malloc pour 1024 une 1ere fois, il reste 3 Ko de libre derrière. Tant qu'on n'y aura pas mis des données vitales, rien à craindre.

ciao...
BruNews, MVP VC++
0
Rejoignez-nous