Discussion :

[tazer]

Bonjour,
je suis sur que c'est une question qui revient assez souvent et pourtant malgré une matinée de recherche sur le forum, je n'ai pas encore eu de réponse.
Mille excuses si j'ai loupé le fil qu'il ne fallait pas louper.
Voila le code suspect :

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
25
26
27
 
// Allocation d'un tableau de nSize element
template <class TYPE> 
inline bool C3Array<TYPE>::Alloc(unsigned long nSize)
{
	InitMembers();
 
	if (nSize>0)
	{
		try{
			m_pData= new TYPE [nSize] ;
			if(m_pData != 0)
			{
				m_nSize=nSize;
				return true;
			}
		}
		catch(CException* e){
			CString msg;
			msg.Format(_T("Pb lors de l'allocation de %d élément(s)"),nSize);
			AfxMessageBox(msg);
			e->Delete() ;
			return false;
		}
	}
	return false;
}

Tout marche bien, puis un jour le matériel a évolué, et donc en augmentant la taille des tableaux, ca ne marche plus. Une exception est générée et le soft renvois le message :

Code :

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

Pb lors de l'allocation de 63148800 élément(s)

Les éléments ici sont des float.

Les caractéristiques de la config sont :
- OS : Win XP SP2.
- DELL T3500 (Xeon 2.93Ghz, 2.87 Go RAM)
- Le soft est développé sous Visual C++ 6.0 utilisant les MFC.
Les info du gestionnaires des taches :
- Mémoire physique (Tot :3012104, Dispo : 1923996, Cahe sys : 491424)
- Le processus (Util Mem : 592592 Ko, Max : 826256 Ko)
- Processus : 42, UC utilisé 1% (message blocant), Charge dédiée 996 Mo

Je ne sais pas quoi donner d'autre comme info avant de tuer le process.

Notre problème est que nous n'avons aucune explication plausible.

A votre avis ?
Merci d'avance.

[Klaim]

Si tu as a besoin de conteneur qui marche avec énormément de contenu, une bonne idée serait d'utiliser STXXL.

[mister3957]

Tu essayes d'allouer 63148800 * 4 octets (240Mo) dans la base, et le gestionnaire des tâches indique qu'il ne reste que 1923996 octets (~1,5Mo) disponibles..

[Emmanuel Deloget]

Si tu as a besoin de conteneur qui marche avec énormément de contenu, une bonne idée serait d'utiliser STXXL.

60 millions d'éléments, c'est gros mais sans plus. Le problème vient du fait qu'il n'y a plus de mémoire. Dans ce cas, new() emets une exception, celle-ci n'est pas catchée, la fonction abort() est appelée et hop, on sort du processus.

Parce que, figure toi, new() ne renvoie jamais un pointeur NULL, même sur VC6. Et voui. Si tu veux obtenir un pointeur NULL, alors il faut appeler p = new (std::nothrow) Type[n].

Autre solution, enregistrer un handler qui va permettre d'effectuer une opération de nettoyage mémoire avant de redonner la main à new (qui va alors tenter de réallouer la mémoire, et ré-appeler le handler en cas d'échec; ...))

Pour ceci, il faut appeler la méthode std::set_new_handler() (voir la doc à ce sujet, je ne me rappelle plus le type du paramètre). En cas d'échec, le handler peut quand même renvoyer false, ce qui va dire à l'opérateur new() de générer une exception.

Autre solution, changer le WorkingSet du processing (fonction SetProcessWorkingSetSize de l'API Windows). Cette fonction te permet de préciser la taille de la zone mémoire dont laquelle ton programme a besoin pour s'exécuter.

[Médinoc]

Parce que, figure toi, new() ne renvoie jamais un pointeur NULL, même sur VC6. Et voui.

Je me permets de te contredire: Je viens de re-tester avec le premier code de ce post, et j'ai droit à un NULL sous VC6 Enterprise Edition.

Edit: La liste "applies to" de cet article KB fait peur. Le problème du NULL touche également VS 2005 Express...

[mister3957]

Il y a aussi le fait que faire un tableau va allouer la mémoire de manière contiguë. Ainsi, tu peux avoir assez de mémoire libre dans le gestionnaire des tâches, l'allocation peut tout de même échouer car la mémoire est fragmentée et il n'y a pas de "trous" assez grand pour stocker tes données.

[Klaim]

60 millions d'éléments, c'est gros mais sans plus. Le problème vient du fait qu'il n'y a plus de mémoire. Dans ce cas, new() emets une exception, celle-ci n'est pas catchée, la fonction abort() est appelée et hop, on sort du processus.

J'ai fait la suggestion de STXXL parceque, à ce que je sache, l'imlpémentation de cette lib va utiliser des fichiers temporaires pour manipuler les données au lieu de tout allouer en mémoire. Ce qui résoudrait, si j'ai bien compris, le problème d'allocation, puisqu'il serait réduit au stricte minimum.

La contrepartie serait alors, forcément, la vitesse de traitement si on parcours toutes les données.

[Emmanuel Deloget]

Il y a aussi le fait que faire un tableau va allouer la mémoire de manière contiguë. Ainsi, tu peux avoir assez de mémoire libre dans le gestionnaire des tâches, l'allocation peut tout de même échouer car la mémoire est fragmentée et il n'y a pas de "trous" assez grand pour stocker tes données.

L'OS peut te dire que la mémoire est contigüe alors qu'en réalité, elle ne l'est pas. Il faut se rappeler que le programme s'exécute dans une zone de mémoire dite virtuelle, qui n'a pas grand chose à voir avec la mémoire physique.

[Médinoc]

Mais l'espace d'adressage du programme peut quand même être fragmenté au point d'empêcher une allocation.

[Emmanuel Deloget]

Mais l'espace d'adressage du programme peut quand même être fragmenté au point d'empêcher une allocation.

Oui, bien sûr

[3DArchi]

Bonjour,

Bonjour,
[...]
A votre avis ?
Merci d'avance.

Mon premier réflèxe aurait été de te dire d'augmenter la mémoire de ton PC ... mais je vois qu'il est déjà à 3Go et que tu utilises Visual 6.
Là, si je suppose que seule ton application tourne et je trouve que le niveau de mémoire disponible est très faible.
Mon conseil : analyser toutes les allocations de ton programme car je pense que ton programme consomme trop de mémoire. L'échec de l'allocation dans ta fonction n'est probablement que la goutte d'eau qui a fait débordé le vase. Deux pistes :
-> mauvaises architecture des données aboutissant à une surconsommation mémoire
-> fuites mémoires aboutissant à diminuer la mémoire disponible.
Bref, le symptôme que tu décris me ferait plus me diriger vers une analyse plus fine de la gestion des allocations dynamiques dans l'ensemble du programme plutôt que de me focaliser uniquement sur l'échec très localisé de la fonction d'allocation.

[tazer]

Bonjour et merci à tous de votre riche collaboration,
En premier je tiens à ajouter un MP que j'ai recu de Pierre Dolez qui dit :

Bonjour,
On ne sait pas ce que contient la classe TYPE.
Si elle contient une cinquantaine, d'éléments, vous n'y arriverez jamais.
A votre place je ferais une organisation de hachage. Ce qui rendra possible toutes les manipulations ultérieures.
Cordialement.

Ceci fait :

Si tu as a besoin de conteneur qui marche avec énormément de contenu, une bonne idée serait d'utiliser STXXL.

C'est une piste de dernier recours, car elle impliquerait de modifier pas mal de code et crois moi, il y'en a. Je me la garde sous la main.

Tu essayes d'allouer 63148800 * 4 octets (240Mo) dans la base, et le gestionnaire des tâches indique qu'il ne reste que 1923996 octets (~1,5Mo) disponibles..

Je n'ai pas fait attention à ce que j'ai écrit, c'est certainement une faute de retranscription.

60 millions d'éléments, c'est gros mais sans plus. Le problème vient du fait qu'il n'y a plus de mémoire. Dans ce cas, new() emets une exception, celle-ci n'est pas catchée, la fonction abort() est appelée et hop, on sort du processus.

Parce que, figure t...

Dans mon cas j'obtient bien un NULL, d'où l''exception et le message d'erreur.

Autre solution, changer le WorkingSet du processing (fonction SetProcessWorkingSetSize d...

Piste intéressante à creuser, pour cela il faut déterminer de combien le processus a besoin en mémoire, à voir si c'est possible. Je me la note.

Il y a aussi le fait que faire un tableau va allouer la mémoire de manière contiguë. A...

Connaissez vous un moyen d'identifier la fragmentation de la mémoire.

-> mauvaises architecture des données aboutissant à une surconsommation mémoire
-> fuites mémoires aboutissant à diminuer la mémoire disponible.

C'est la raison qui parle, je pense que nous devons y passer tôt ou tard.

On ne sait pas ce que contient la classe TYPE.

Il ne contient, dans ce cas, que des float.

Malheureusement, depuis, tous le monde est déjà passé sur d'autres projets (jugés plus urgents) et ce problème est refoulé au fond des priorités. Il reste néanmoins critique, à mon sens.

La solution (rustine) que nous avons mis en place actuellement et de traiter les données sur 2 tableaux de demi taille chacun, et là ca passe, ce qui conforte la cause de fragmentation de la mémoire.

A quel point c'est crédible ?

[Emmanuel Deloget]

C'est une piste de dernier recours, car elle impliquerait de modifier pas mal de code et crois moi, il y'en a. Je me la garde sous la main.

Ouh ! bug d'architecture ! Vilain vilain vilain !

La façon dont les données sont stockées et censée être un détail d'implémentation, comme tu le vois maintenant. Il faut encapsuler tout ça (peut être dans une classe "collection" ou "dictionnaire", ou autre chose, selon la sémantique intrinsèque des données elles-même.

Dans mon cas j'obtient bien un NULL, d'où l''exception et le message d'erreur.

Comportement pré-standard donc. Vous n'avez pas moyen de passer à une autre version de Visual ? Les dernières versions (2005, 2008 et 2010) sont gratuites dans leur déclinaison "Express Edition". Il n'y a pas tout, certes, mais si vous ne faites pas de MFC, ça ne devrait pas poser de problème. Un très grand nombre de bugs ont été corrigés. Le support du standard est maintenant tout à fait correct, mis à part certains points très particuliers (comme les règles d'instanciation des templates).

Piste intéressante à creuser, pour cela il faut déterminer de combien le processus a besoin en mémoire, à voir si c'est possible. Je me la note.

Si vous manipulez énormément de données, c'est peut-être une solution. Ou un nouveau problème

Connaissez vous un moyen d'identifier la fragmentation de la mémoire.

Non, hélas. Tu peux maintenir une map (en surchargeant new et delete pour effectuer la mise à jour de la map en question), et voir ce que ça donne.

Malheureusement, depuis, tous le monde est déjà passé sur d'autres projets (jugés plus urgents) et ce problème est refoulé au fond des priorités. Il reste néanmoins critique, à mon sens.

La solution (rustine) que nous avons mis en place actuellement et de traiter les données sur 2 tableaux de demi taille chacun, et là ca passe, ce qui conforte la cause de fragmentation de la mémoire.

Les plantages systématiques sont en low priority ?

Ca c'est fun et courageux

A quel point c'est crédible ?

C'est tout à fait crédible. Mon blabla précédent ne visait pas à écarter cette cause, mais juste à dire qu'elle ne se produisait pas si souvent que ça. Quoi qu'il en soit, elle se produit quand même lorsqu'on gère des tailles mémoire importantes.

Il y a en outre une autre chose qui demande à être vérifiée : le nombre réel d'éléments alloués. Tu utilises un std::vector<>, et sa taille (obtenue par la méthode size()) n'est pas liée à l'espace mémoire qui a été réservé (obtenu pas la méthode capacity()). C'est peut-être pour ça que ça marche avec deux vecteurs plus petits : la taille allouée peut être en fait très inférieure à la taille d'un seul vecteur contenant tous les éléments. L'algorithme qui préside à l'extension d'un vecteur est facile à comprendre, mais les interactions qu'il entraîne peuvent être complexes à prévoir. L'utilisation de la méthode reserve() permets d'avoir un contrôle plus fin sur ce qui se passe.

[tazer]

Ouh ! bug d'architecture ! Vilain vilain vilain ! ...

Le changement du code "présumé" coupable n'est pas compliqué an tant que tel ainsi que les problèmes de compil qui en résulterons.
S'assurer que l'on n'a rien cassé et que tout marche comme avant (même les soft liés à des matériels dont on ne dispose plus) c'est ce qui fait peur. D'autant plus que le code en question date du début des années 2000 voir 90 (voir même 80) et qu'une multitude d'applications ont été construites dessus.

Comportement pré-standard ... Vous n'avez pas moy...

C'est en cours sur les nouveaux développements pour les visual 2008, 2010. Par contre nos dév sont très liés aux MFC, déjà en gardant les MFC, il a fallu du temps. S'en passer n'est pas productif.

En résumé, et là on sort un peu du sujet, nous sommes amené à manipuler des données de taille astronomique, mais nous restons quand même une entité à taille humaine.

[Emmanuel Deloget]

Le changement du code "présumé" coupable n'est pas compliqué an tant que tel ainsi que les problèmes de compil qui en résulterons.
S'assurer que l'on n'a rien cassé et que tout marche comme avant (même les soft liés à des matériels dont on ne dispose plus) c'est ce qui fait peur. D'autant plus que le code en question date du début des années 2000 voir 90 (voir même 80) et qu'une multitude d'applications ont été construites dessus.

Là, je n'ai qu'une solution : la relecture de Refactoring de M. Fowler Et du test unitaire. Beaucoup de test unitaire. Avant de commencer le refactor.