Ca dit seulement que sur un OS 32 bits tu ne peux en général pas créer un espace virtuel utilisateur > 2Go.
- W
Version imprimable
La question initiale était "comment le détecter", ben voila c'est fait. C'est normal qu'il y ait des limites sur l'allocation mémoire, on va pas en vouloir aux os pour ça :)
Nope, la question initiale était "j'alloue 1Go et çà plante".
Ce que l'exemple montre c'est qu'on ne peut pas planter le système en allouant 1Go de mémoire virtuelle mais peut être en s'en servant.
=> nous avons quelques idées sur le problème 'initial" mais toujours pas cerné le problème.
- W
Heu, t'es aveugle ou quoi? Le message affiché dans sa console est on ne peut plus clair, ici ce n'est pas un plantage qui se produit, mais une levée d'exception lors du new parfaitement attendue, bref exactement ce qui est supposé se passer selon le standard C++. Dans ce cas ça plante après bien entendu, ce n'est pas supposé faire autre chose quand on ne gère pas les exceptions.
Alors je suis bien d'accord qu'il faut trouver une solution, que ce soit en utilisant un système à la mmap fournis par le système, non fournis par le système ou tout simplement en ne réservant pas autant de mémoire. Néanmoins ça montre bien, fort heureusement, que le mode de fonctionnement que tu as évoqué à base de plantage complètement aléatoire, inévitable et impossible à prévoir lors d'un accès à l'une des pages allouées n'est pas le mode de fonctionnement utilisé par son système. Et ça c'est rassurant (si si).
Les exceptions ça s'attrape hein... try/catch.
Il y a deux tests:
1 - j'alloue moins de 2Go (et beaucoup plus aue 1Go) et ca ne plante pas,
2 - j'alloue plus de 2 Go et çà plante comme attendu - parce qu'on dépasse la limite de l'espace utilisateur en 32 bits.
Dans le cas (2) mmap ne sert à rien, il faut un OS 64 bits.
Ce que j'ai fait n'est sans doute pas ce qu'a fait l'auteur du post: nous ne savons toujours pas ce qui plante de son côté.
Mon test vérifie simplement qu'on peut allouer un espace virtuel important sans que ela retourne d'erreur même si on n'a ni la RAM ni le swap.
-W
Je suis d'accord mais mon test avait pour propos de montrer que:
1 - on peut allouer plus de 1Go sans que cela retourne d'erreurs,
2 - la mecanisque d'exception se met en marche lorsqu'on dépasse la limite de l'espace virtuel.
Donc que le problème soumis originallement était 'ailleurs' que dans le retour du new.
- W
Quand une erreur arrive après l'allocation, ça veut dire que tu es sous Linux avec l'allocation mémoire optimiste (le truc dont parle JolyLoic) activée. Dommage pour toi.
Normalement, s'il n'y a pas assez de mémoire (physique + swap) disponible, new doit lancer une exception C++ std::bad_alloc (ou retourner NULL pour les versions obsolètes). S'il ne fait ni l'un ni l'autre, c'est que l'allocation optimiste est active.
Et c'est un vrai fléau, mais c'est toujours mieux que d'autres politiques d'allocation qu'on m'a mentionnées sur certains systèmes unixoïdes, comme tuer automatiquement un process pour libérer de la mémoire...
A ce propos il semblerait qu'il ait disparu :P
Non non, pas du tout !
Merci pour toutes vos réponses, je suis en train de trouver la solution...
Effectivement, sous Windows, j'ai bien une exception qui est lancée => nickel.
Pour Linux, je m'y attaque aujourd'hui...