Discussion :

[Demerzel_01]

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 :

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.

[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é...)

[Laurent Gomila]

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

[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...

[NewbiZ]

Je dis peut être une bêtise mais new ne renvoie pas NULL quand il n'y a plus assez de mémoire ?

[Swoög]

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

[JolyLoic]

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;

[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 ...

[Demerzel_01]

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.

[Jean-Marc.Bourguet]

On peut avoir une idee de la valeur de Size?

[Swoög]

Dans son premier post :

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

[Demerzel_01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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.

[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

[loufoque]

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.

[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 .....

[Laurent Gomila]

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.

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.

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.

[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.

[Swoög]

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 ?

[Jean-Marc.Bourguet]

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).