Operateur "new" renvoi NULL

Version imprimable

04/07/2006, 19h13
Demerzel_01

Operateur "new" renvoi NULL

Bonjour,
Je cherche la raison pour laquelle l'operateur new me renvoie l'adresse NULL lors de l'allocation d'un tableau.

Extrait du code ou le problème se produit :

Citation:

void Mdct::InverseTransform(float *In,float *Out)
{
float *Real;
float *Imag;

Real=new float[Size];
…
}

Au bout d'un certain nombre de création d'objet Mdct, et d'appel à cette fonction InverseTransform(), une erreur apparaît et j'ai pu voir grâce au debugger que l'adresse de mon pointeur "Real" est à zéro juste après le "new", size étant bien égal a une valeur correcte (1024 en l'occurrence) et ma mémoire n'étant pas saturée.

Je pense bien sûr que le problème ne vient pas de cet extrait de code, mais comme je ne connais aucune cause possible au renvoi de l'adresse NULL par un "new", toute idée serait la bienvenue.

Merci d'avance pour vos réponses.
04/07/2006, 19h16
Swoög

il semble impossible que new renvoye NULL puisque s'il échoue, il est censé lever une exception bad_alloc, tu es sûr d'avoir bien effectué l'interogation sur la valeur de Real après l'affectation, et non après le retour de new (ce sont deux opérations différentes, et il est possible que ton débuggueur s'arrète entre les deux, ça m'est déjà arrivé...)
04/07/2006, 19h24
Laurent Gomila

Certrains vieux compilos non conformes (Visual C++ 6) renvoient NULL lorsque new échoue.
04/07/2006, 21h31
Médinoc

Si je me souviens bien, ils étaient conformes avant que les normes ne changent...

Et Franchement, "C'était mieux avant". Mais bon, ce doit être mon esprit en C qui me dit ça...
Il faut dire que personne n'aimerait que malloc() fasse une segfault au lieu de retourner NULL...
04/07/2006, 21h55
NewbiZ

Je dis peut être une bêtise mais new ne renvoie pas NULL quand il n'y a plus assez de mémoire ?
04/07/2006, 22h17
Swoög

Citation:

Envoyé par Médinoc

Il faut dire que personne n'aimerait que malloc() fasse une segfault au lieu de retourner NULL...

new ne fait pas de segfault, il lève une exception bad_alloc (mm en cas de saturation de la mémoire, et Demerzel_01 a précisé que sa RAM n'était pas saturée)... je vois pas où est le problème, et perso, je préfère l'exception, ça évite justement les segfault
05/07/2006, 01h38
JolyLoic

Citation:

Envoyé par Médinoc

Si je me souviens bien, ils étaient conformes avant que les normes ne changent...

Et Franchement, "C'était mieux avant". Mais bon, ce doit être mon esprit en C qui me dit ça...

Un new qui retourne NULL en cas d'échec, ça veut dire qu'il faut tester chaque allocation. Un new qui lance une exception, ça veut dire qu'avec un handler global unique au programme, on peut gérer proprement et sans rien oublier tous les cas d'allocation posant problème dans les cas classiques (échec -> message et arrêt propre du programme).

Je ne vois aucun avantage en l'occurence à un new qui ne lancerait pas d'exception, mais de toute façon, si c'est ce que tu veux, je t'invite à utiliser systèmatiquement T* t = new (nothrow) T;
05/07/2006, 02h02
Luc Hermitte

Hum. Quand je ne peux pas acquérir la mémoire nécessaire à mes opérations, je ne continue pas avec le traitement en cours. Je l'avorte. Et pour ça, les exceptions sont là. Alors entre tester moi-même pour lever l'exception et la regarder se lever toute seule ...
05/07/2006, 10h07
Médinoc

C'est vrai, j'ai un peu de mal avec les exceptions.
Dépuis Java qui en lance une pour un oui ou pour un non, j'ai appris à les haïr.
Mais je reconnais que les exceptions peuvent parfois s'avérer quasiment-indispensables, quand on fait des initialisations dans un constructeur.

Quand au renvoi de NULL en cas d'échec, en habitué du C il ne me gênait pas. Mais Visual (je ne sais plus quelle(s) version(s)) me faisait un warning bizarre avec nothrow...
05/07/2006, 11h55
Demerzel_01

Citation:

Envoyé par Laurent Gomila

Certrains vieux compilos non conformes (Visual C++ 6) renvoient NULL lorsque new échoue.

j'utilise visual.net
J'ai tenté de lancer devpartner en mode "error detection" pour voir si celui ci me detectait une erreur lors de l'execution du code.... mais non. De plus, executer le code avec devpartner fait que celui-ci ne plante plus.
05/07/2006, 14h11
Jean-Marc.Bourguet

On peut avoir une idee de la valeur de Size?
05/07/2006, 14h17
Swoög

Dans son premier post ;) :

Citation:

Envoyé par Demerzel_01

[...]size étant bien égal a une valeur correcte (1024 en l'occurrence)[...]

En simplifiant mon code a l'extreme il apparait une erreur de "stack overflow", cela pourrait il expliquer mon probleme ?

Sinon mon code effectue la tache suivante :
Je parcours un arbre de maniere recursive :
un noeud de l'arbre verifie s'il a un descendant, si ce n'est pas le cas il crée un certain nombre de descendant du rang +1 de l'arbre et leur effectue un traitement visant a éliminer certaines branches de l'arbre, et si c'est cas il va pointer sur le noeud suivant afin d'effectuer la meme procedure.

exemple du code utilisé(si ca peut aider a la comprehension):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 void Branch::Feed(float *signal) { int n; if(dead) return ; if(Next) { for(n=0;n<2;n++) Next[n].Feed(signal); } else { Next = new Branch[2]; Next[0].Init(this,0); Next[1].Init(this,1); for(n=0;n<2;n++) Next[n].Result(signal); } SimplifyTree(); }
Comme je le disais, je ne sature pas ma RAM, mais y a t il une limite "physique" a ce genre d'utilisation de recursion ? la je bloque a environ 3000 etages de mon arbre.

05/07/2006, 17h24
Laurent Gomila

Les variables locales des fonctions sont empilés sur la pile, et ne sont libérés qu'à la fin de la fonction. Le problème avec la récursion c'est que tant que tu n'as pas atteint la fin de la récursion, rien n'est libéré. Et la pile a une taille assez limitée.

Essaye de déclarer tes variables locales ailleurs, ou mieux : remanier ton algo pour éviter ce genre de récursion.
05/07/2006, 17h28
harsh

De toute maniere, j'ai deja fait tourner des softs qui prenait plus de memoire que de RAM presentent et je n'ai pas eu de stack overflow, je presume donc que Windows ecrit alors sur les disques (remarquez, le prog tournait mieux que je ne l'aurais pensé).

EDIT: pourquoi la pile a t elle une taille limite???

re-EDIT: je fais souvent tourner des prog tres/trop gourmand de traitement d'images et je n'ai jamais atteint une quelconque limite 8O
05/07/2006, 17h33
loufoque

Citation:

Si je me souviens bien, ils étaient conformes avant que les normes ne changent...

MSVC6 est antécédant à la première norme de C++, issue en 1998.
05/07/2006, 17h36
Demerzel_01

Je viens de voir tout plein de topics relatifs a la récursivité et/ou dépassement de pile, je vais donc allez potasser cela.

Ceci dit, cela peut il expliquer mon problème initial ? Sur la version "lourde" de mon code, je ne voyait pas ce "stack overflow". En release, je me faisais ejecter du programme sans qu'il soit fini et sans message d'erreur :? et en debug je voyais apparaitre un new me renvoyant NULL .....
05/07/2006, 18h12
Laurent Gomila

Citation:

pourquoi la pile a t elle une taille limite???

La pile étant faite pour recevoir les variables locales et les paramètres de fonction, elle peut être accédée très rapidement mais de ce fait doit être limitée. Comme tu le sais, en informatique, accés plus rapide rime avec taille plus faible.

Citation:

je fais souvent tourner des prog tres/trop gourmand de traitement d'images et je n'ai jamais atteint une quelconque limite

Très certainement parce que tu utilises le free-store (ou tas) (l'espace mémoire utilisé par new).
Pour faire péter la pile il n'y a que deux moyens : variable locale trop grosse (tableau de 50 000 éléments par exemple), ou récursivité trop lourde. Donc ce n'est pas étonnant que tu ne sois jamais tombé sur le problème.

Citation:

Ceci dit, cela peut il expliquer mon problème initial ? Sur la version "lourde" de mon code, je ne voyait pas ce "stack overflow". En release, je me faisais ejecter du programme sans qu'il soit fini et sans message d'erreur et en debug je voyais apparaitre un new me renvoyant NULL .....

Comme je te l'ai dit, new manipule le free-store, donc aucun rapport avec la pile a priori.
05/07/2006, 19h19
Demerzel_01

j'ai juste augmenté la taille de ma pile et mon code a l'air de s'executer sans problème et jusqu'au bout. cette histoire de new restera donc un mystère :?

Merci pour vos réponses en tout cas :D
05/07/2006, 22h39
Jean-Marc.Bourguet

Citation:

Envoyé par Laurent Gomila

La pile étant faite pour recevoir les variables locales et les paramètres de fonction, elle peut être accédée très rapidement mais de ce fait doit être limitée. Comme tu le sais, en informatique, accés plus rapide rime avec taille plus faible.

La pile est une zone mémoire comme une autre.

Je vois deux raisons de limiter la taille de la pile sur des OS un espace mémoire par process:
- certains peuvent réserver directement la mémoire pour la pile maximale (en mémoire ou en place dans le swap, ça revient au même), donc allouer trop de pile, c'est gaspiller une ressource.
- on ne sait en pratique avoir au maximum 2 zones de tailles dynamiques (elles sont aux extrémités d'un espace partagé et grandissent l'une vers l'autre), or on en a en pratique plus le tas, les piles et l'espace pour les fichiers mappés en mémoire (dont les bibliothèques dynamiques). Des ceux-ci, les piles sont ceux qui peuvent le plus raisonnablement être contraints (et en plus, il y en a un nombre variable: autant qu'il y a de threads).

A noter que même en travaillant pas mal avec des algo récursifs sur des graphes relativement gros (centaines de milliers de noeuds), je n'ai jamais eu de problème de dépassement de pile que quand j'avais un problème de fond -- "grosses" variables locales pouvant être partagées entre les appels récursifs, profondeur de pile proportionnelle à la taille des données quand il est possible de se limiter au logarithme de celle-ci... Sur le genre d'algo que j'ai programmés et avec le genre de graphes que nous traitons, une profondeur de 3000 serait typique de ce dernier problème.
05/07/2006, 23h21
loufoque

Citation:

(et en plus, il y en a un nombre variable: autant qu'il y a de threads).

C'est pas autant que de processus plutôt ?
06/07/2006, 08h48
Jean-Marc.Bourguet

Citation:

Envoyé par loufoque

C'est pas autant que de processus plutôt ?

Les processus ont generalement des espaces d'adressages separes.
06/07/2006, 19h30
swirtel

un process 32 bits sur OS 32 bits se résume à une limitation de 2Go de mémoire (ram + swap).

maintenant si je me trompe qu'on me le dise.
06/07/2006, 21h31
Swoög

Citation:

Envoyé par swirtel

un process 32 bits sur OS 32 bits se résume à une limitation de 2Go de mémoire (ram + swap).

maintenant si je me trompe qu'on me le dise.

sauf erreur de ma part, avec 32bits on peut adresser 4 Go non ?
07/07/2006, 09h18
Jean-Marc.Bourguet

Citation:

Envoyé par swirtel

un process 32 bits sur OS 32 bits se résume à une limitation de 2Go de mémoire (ram + swap).

maintenant si je me trompe qu'on me le dise.

Je ne suis pas sur de quoi tu parles.

S'il s'agit du fait que les OS reservent generalement une partie de l'espace d'adressage des process pour leur usage et si au debut les OS se reservaient effectivement souvent la moitie, actuellement on peut configurer la plupart des OS pour laisser plus de place aux process que 2 Go (mais je ne suis pas sur que ce soit le cas de Windows).
07/07/2006, 09h43
Médinoc

Tu as un mode 3Go/1Go disponible sous un WindowsNT moderne.
Quant à Win64, c'est une autre histoire.

Citation:

Envoyé par Swoög

sauf erreur de ma part, avec 32bits on peut adresser 4 Go non ?

Sous Win32, c'est (normalement) 2Go spécifiques au process et acessibles en mode utilisateur, et 2Go partagés entre tous et accessibles uniquement en mode kernel (tout en étant toujours dans le process)