Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb de compréhension d'allocation

9 réponses
Avatar
dug8C
Bonjour,

Je ne comprend pas pourquoi lorsque je lance le m=EAme ex=E9cutable en
m=EAme temps, les allocations dynamiques sont les m=EAmes sur dans les 2
instances.
Lorsque je cr=E9e un int sur le tas, le syst=E8me devrait me donner une
place non attribu=E9e, non ?

Apparement ce doit =EAtre un comportement normal, mais je m'attendais =E0
ne pas avoir la m=EAme m=E9moire allou=E9e.
Est-ce vraiment le cas ?

voila mon code:
#include <iostream>

int main()
{
std::cout << "Hello world!" << std::endl;

int* int1 =3D new int;
std::cout << " int1:" << int1<< std::endl;
int* int2 =3D new int;
std::cout << " int2:" << int2 << std::endl;

int wait;
std::cin >> wait;
delete int1;
delete int2;
std::cout << "bye bye world!" << std::endl;

return 0;
}


Je compile ce programme et le lance le programme 2 fois =E0 partir du
m=EAme =E9x=E9cutable. Je suis sous windows et j'utilise g++.

Sortie:
Dans le 1ere programme:
Hello world!
int1:0x3d2468
int2:0x3d24d0

dans le 2eme:
Hello world!
int1:0x3d2468
int2:0x3d24d0

.=2E.

9 réponses

Avatar
Jean-Marc Bourguet
writes:

Je ne comprend pas pourquoi lorsque je lance le même exécutable en
même temps, les allocations dynamiques sont les mêmes sur dans les 2
instances.


Normal: depuis les années 60, on a tendance à donner à chaque process son
propre espace mémoire. Il a fallut un peu de temps pour que cela se
répendent sur les micro-processeurs, mais pour les x86, on y est depuis le
80286 sorti en 1982. Il a fallu encore un peu de temps pour que les OS s'y
mettent, DOS ne l'a jamais fait, Windows le peut depuis au moins 3.0.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
adebaene
wrote:
Bonjour,

Je ne comprend pas pourquoi lorsque je lance le même exécutable en
même temps, les allocations dynamiques sont les mêmes sur dans les 2
instances.
Lorsque je crée un int sur le tas, le système devrait me donner une
place non attribuée, non ?

Apparement ce doit être un comportement normal, mais je m'attendais à
ne pas avoir la même mémoire allouée.
Est-ce vraiment le cas ?

<snip>

Sortie:
Dans le 1ere programme:
Hello world!
int1:0x3d2468
int2:0x3d24d0

dans le 2eme:
Hello world!
int1:0x3d2468
int2:0x3d24d0


Dans un OS multi-taches moderne, chaque processus se voit alloué son
propre espace d'adressage mémoire "virtuel", qui au départ est
identique pour chaque processus. Le processeur er l'OS collaborenet
pour mapper ces addresses "virtuelles" en adresses physiques.

Quand 2 processus font exactement la même chose en terme d'allocation,
il se retrouvent avec exactement les mêmes adresses virtuelles
allouées. Par contre, ces addresses virtuelles sont mappées sur des
adresses physiques différentes pour chaque processus, mais tu n'a pas
accès à ces addresses physiques (c'est le "memroy manager" de ton OS
qui se charge de ces détails).

Arnaud

Avatar
dug8C
<snip>

Dans un OS multi-taches moderne, chaque processus se voit alloué son
propre espace d'adressage mémoire "virtuel", qui au départ est
identique pour chaque processus. Le processeur er l'OS collaborenet
pour mapper ces addresses "virtuelles" en adresses physiques.

Quand 2 processus font exactement la même chose en terme d'allocation,
il se retrouvent avec exactement les mêmes adresses virtuelles
allouées. Par contre, ces addresses virtuelles sont mappées sur des
adresses physiques différentes pour chaque processus, mais tu n'a pas
accès à ces addresses physiques (c'est le "memroy manager" de ton OS
qui se charge de ces détails).

Arnaud


Merci pour vos réponses, j'avais oublié que j'étais dans un
environnement multi-proccess.

Avatar
espie
In article ,
wrote:
Dans un OS multi-taches moderne, chaque processus se voit alloué son
propre espace d'adressage mémoire "virtuel", qui au départ est
identique pour chaque processus. Le processeur er l'OS collaborenet
pour mapper ces addresses "virtuelles" en adresses physiques.

Quand 2 processus font exactement la même chose en terme d'allocation,
il se retrouvent avec exactement les mêmes adresses virtuelles
allouées. Par contre, ces addresses virtuelles sont mappées sur des
adresses physiques différentes pour chaque processus, mais tu n'a pas
accès à ces addresses physiques (c'est le "memroy manager" de ton OS
qui se charge de ces détails).


Et dans un OS multi-taches tres moderne, ce n'est plus le cas.

Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,
dans la mesure du possible. C'est deja le cas dans OpenBSD, et ca fait
partie des choses qui devraient changer dans Windows avec Vista (peut-etre
meme deja avec certains SP).

Evidemment, ca va rendre le debug un tantinet plus complique,
legerement plus delicat de reproduire les memes erreurs
d'une fois a l'autre...

Avatar
adebaene
Marc Espie wrote:
In article ,
wrote:
Dans un OS multi-taches moderne, chaque processus se voit alloué son
propre espace d'adressage mémoire "virtuel", qui au départ est
identique pour chaque processus. Le processeur er l'OS collaborenet
pour mapper ces addresses "virtuelles" en adresses physiques.

Quand 2 processus font exactement la même chose en terme d'allocation,
il se retrouvent avec exactement les mêmes adresses virtuelles
allouées. Par contre, ces addresses virtuelles sont mappées sur des
adresses physiques différentes pour chaque processus, mais tu n'a pas
accès à ces addresses physiques (c'est le "memroy manager" de ton OS
qui se charge de ces détails).


Et dans un OS multi-taches tres moderne, ce n'est plus le cas.

Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,
dans la mesure du possible. C'est deja le cas dans OpenBSD, et ca fait
partie des choses qui devraient changer dans Windows avec Vista (peut-etre
meme deja avec certains SP).

Evidemment, ca va rendre le debug un tantinet plus complique,
legerement plus delicat de reproduire les memes erreurs
d'une fois a l'autre...


Oui, ce serait bien que ce soit débrayable en phase de
développement....

Arnaud


Avatar
loufoque
Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,


Je préfère ne pas faire de faille dans mon code plutôt que de rendre
l'exploitation de ces failles difficile.

Avatar
Sylvain
loufoque wrote on 02/10/2006 17:49:
Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,


Je préfère ne pas faire de faille dans mon code plutôt que de rendre
l'exploitation de ces failles difficile.


comment rends-tu le stockage d'un credential infaillible dans ton code?
(sachant que de manière déterministe il peut être stocké toujours à la
même adresse logique).

Sylvain.


Avatar
espie
In article <452134e8$0$283$,
loufoque wrote:
Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,


Je préfère ne pas faire de faille dans mon code plutôt que de rendre
l'exploitation de ces failles difficile.


Moi-aussi. Mais ca ne change rien au fait qu'il t'arrive d'utiliser le
code pondu par d'autres. Un peu difficile d'auditer en totalite le code
d'un navigateur web, par exemple, meme ecrit dans un langage de haut
niveau...

Pour revenir au sujet du newsgroup courant, meme s'il est possible
de faire des choses tres propres et solides en C++, vu le niveau de
complexite du langage, il me semble clair qu'il n'est pas forcement
maitrise de facon suffisante par tous ceux qui s'en servent, et donc
qu'il y a dans la nature des applications, disons pas trop sures pour
etre gentil.


Avatar
Arnaud Debaene
"loufoque" a écrit dans le message de news:
452134e8$0$283$
Ca fait maintenant quelques temps que les problemes de securite ont
conduit certains designers d'OS a randomiser les adresses memoire,


Je préfère ne pas faire de faille dans mon code plutôt que de rendre
l'exploitation de ces failles difficile.


On en est tous là, mais est-ce que tu as un moyen de *garantir* que tu ne
feras pas d'erreur?

Une bonne sécurité informatique, c'est une sécurité en profondeur, avec
plusieurs niveaux de défense cummulatifs. Donc, utiliser des méthodes et
conventions de codage qui limitent les risques d'exploits dans ton code,
très bien, mais si on peut randomiser un peu l'espace d'adressage mémoire en
plus, ce n'en est que mieux....

Arnaud