Discussion :

[Gellius31]

Bonjour,

J'ai écris un programme de tri en Langage C, compatible Visual Studio 2005, Cygwin, gcc, Unix et Borland (Borland® Developer Studio 2005).

Tout fonctionne très bien avec les autres compilateurs, mais le Borland - Projet C++ - bcc32 - refuse de m'allouer 950 Mo de mémoire... ??? J'ai bien regardé les paramètres de compilation et de linkeur - ( {heap, stack} reserve | commit size) mais je n'ai rien trouvé... Une idée ???

J'ai, évidemment, plus de 950 Mo de RAM, de disponible....

Merci.

Source : iMaxSize = 1000000000
--------

Code :

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

1
2
3
4
5
6
7
8
...
		if ( !(pVect->pData = (char *) malloc ( (iMaxSize +  1) * sizeof (char))) ) {
			snprintf (pErr, ERR_LEN + 1,
				"%s\nEchec allocation structure Vector (Data) - Size = %d Ko",
				pErrPrefix, (int) (((iMaxSize +  1) * sizeof (char)) / 1024) );
			return (NULL);
		}
...

Output :
--------
AcbSortC - Version V.0.95 - Dec 19 2007 - 11:13:55

Start at : Wed Dec 19 16:09:07 2007

Utilisation memoire :
---------------------
File(s) size : 7960246 Ko
Memory in use : 43 %
Physical memory : 2088432 Ko
Free physical memory : 1188304 Ko
Page file : 4023844 Ko
Free page file : 3277816 Ko
Virtual memory : 2097024 Ko
Free virtual memory : 2076744 Ko
BUFFSIZE : 976562 Ko
LGRMAX : 333 char
Full data size : 7960246 Ko
Full index size : 95618 Ko
Data size : 964971 Ko
Index size : 11591 Ko
Index occurences : 2967358 occurs

AcbSortC - FATAL ERROR

Echec allocation structure Vector (Data) - Size = 964971 Ko

[salseropom]

Salut,
de mémoire, je crois que malloc alloue des blocs mémoire consécutifs. Donc peut-être que tu n'as pas 950 Mo de disponible, consécutif. Et si tu essayais de faire deux tableaux plus petits ?

[souviron34]

en plus, je veux pas dire, mais allouer 950 Mo ....

A mon avis y aurait comme un petit probleme de conception.....

[Gellius31]

1.) Comme je vous l'ai dit, j'ai bien plus 950 Mo disponible...

=> Free physical memory : 1188304 Ko

2.) malloc() peut allouer jusqu'à 2 Go, ce que j'ai déjà fait.

Prototype : void * malloc (size_t size);

3.) Il n'y a pas de raison que cela ne fonctionne pas puisque cela fonctionne sous Visual Studio, Cygwin, OpenBSD, Linux, et Aix...

4.) Problème de conception... Pourquoi ne pas allouer 2 Go, lorsqu'une fonction C Ansi l'autorise ? C'est un programme de tri (QuickSort)... Je trie des fichiers de 60 Go !!! Tu veux que je travaille avec des blocs de 5 Ko ???

[souviron34]

il esrt simplement plus portable, si tu veux pas te demander un jour (ou tes clients ou ton employeur) pourquoi le programme plante, au minimum de passer la taille en paramètre de lancement...

Et miser sur le fait qu'un ordi aura 2Go de mémoire... A part si c'est pour tourner une seule fois (pour re-trier une base), mais sinon c'est pas mal violent comme approche...

Et quand je parle de problème de conception, c'est que le tri (l'élément qui sert à trier) ça m'étonnerait qu'il se fasse sur 2 Go, même si la base fait 2go ou 60... (si c'est par exemple le numéro de ligne plus 60 caractères, ça ne fait que 64 * 20 millions d'enregistrements par exemple, c'est à dire 1.3 go. Si c'était un numéro et 1 autre entier, c'est 160 Mo (pour 20 millions d'enregistrements (quelle que soit leur taille) triés simultanément))


Enfin, ce que j'en dis, c'est mon opinion.... je ne connais pas ton problème...

Après on se demande pourquoi tous les 6 mois il y a de nouvelles générations - souvent incompatibles - avec plus de mémoire et plus de CPU que les calculs d'hydrodynamique et des problèmes à N corps nécessitent ..

[Pierre Maurette]

1.) Comme je vous l'ai dit, j'ai bien plus 950 Mo disponible...

=> Free physical memory : 1188304 Ko

2.) malloc() peut allouer jusqu'à 2 Go, ce que j'ai déjà fait.

Prototype : void * malloc (size_t size);

3.) Il n'y a pas de raison que cela ne fonctionne pas puisque cela fonctionne sous Visual Studio, Cygwin, OpenBSD, Linux, et Aix...

C'est donc que vous n'appelez pas le "bon" malloc()
J'ai un peu laissé tomber Borland, mais le problème me rappelait quelque chose, j'ai testé ce matin sur une Turbo C++.
Effectivement, si vous laissez coché Projet / Options / Lieur / Liaison / Utiliser la RTL dynamique, vous utilisez un cc32?0.dll. Si vous le décochez, vous liez quelque chose en statique et ça marche alors comme vous le souhaitez.
Il faudrait voir maintenant comment vous allez déployer, et s'il est possible d'utiliser msvcr???.dll.

4.) Problème de conception... Pourquoi ne pas allouer 2 Go, lorsqu'une fonction C Ansi l'autorise ? C'est un programme de tri (QuickSort)... Je trie des fichiers de 60 Go !!! Tu veux que je travaille avec des blocs de 5 Ko ???

"Expliquez moi ce dont vous avez besoin, je vous expliquerai comment vous en passer." Coluche.
Dans le même genre, êtes-vous en C (lié ou non à du C++) ou en C++ ? Dans le premier cas, ne pas caster le malloc(). Dans le second, peut-être utiliser new.

[Gellius31]

Bon, je ne veux pas m'éloigner du sujet...

A la base, j'ai un problème que je veux régler.

Je veux faire un malloc() de 950 Mo, alors que la fonction permet d'allouer jusqu'à 2Go, et cela plante en Borland C++ 2005 alors que cela fonctionne avec tous les autres systèmes testés (Visual Studio, Cygwin, OpenBSD, Linux, Aix...) et que j'ai suffisamment de RAM disponible...

Est-ce que quelqu'un a une explication ?

[Pierre Maurette]

Bon, je ne veux pas m'éloigner du sujet...

A la base, j'ai un problème que je veux régler.

Je veux faire un malloc() de 950 Mo, alors que la fonction permet d'allouer jusqu'à 2Go, et cela plante en Borland C++ 2005 alors que cela fonctionne avec tous les autres systèmes testés (Visual Studio, Cygwin, OpenBSD, Linux, Aix...) et que j'ai suffisamment de RAM disponible...

Est-ce que quelqu'un a une explication ?

Projet / Options / Lieur / Liaison / Utiliser la RTL dynamique ?

[Gellius31]

Ma réponse n'était pas destinée à Pierre, son message s'est intercalé dans ma réponse...

Je jette un coup d'œil et je te répond...

Sinon, je suis en C pur, pour un maximum de portabilité, donc pas de new(), j'utilise le compilo bcc32, simplement parce que, à priori, il n'y a plus de compilo C avec les environnement Visual Studio ou Borland.

Ayant déjà eût des problèmes à l'époque avec le Turbo C 2.0, j'ai même essayé un "farmalloc()"... Mais j'ai un peu abusé sur ce coup là...
Un LocalAlloc() SDK, produisait également la même sanction.

Sinon, merci pour la citation "Expliquez moi ce dont vous avez besoin, je vous expliquerai comment vous en passer.", qui m'a rendu le sourire et que j'ai trouvé de circonstance !

[Gellius31]

Well done Pierre, it's working ! So good !

Many thanks.

[Gellius31]

Pierre pendant que je tiens...

Sais-tu pourquoi Visual Studio ne génère pas de stack overflow en exec (mode release) ?

Je t'explique...
J'ai un tri QuickSort()... Fonction récursive et je trie de gros fichiers... Autour de 60 Go... Si un fichier est malheureusement déjà trié, la fonction récursive s'empile violemment... Jusqu'à explosé la stack...

Et là, si la programme est compilé avec Visual Studio (), le programme me rend gentiment la main sans exploser ? J'ai bien essayé de regarder autour des stack size... Mais nada...
http://msdn2.microsoft.com/en-us/lib...ks(VS.71).aspx

La solution serait de vérifier que le programme n'est pas déjà trié en amont, mais cela n'est pas aussi simple que cela...

A noter que gcc-cygwin, résiste... Mais problème de performance...

[Pierre Maurette]

Sinon, je suis en C pur, pour un maximum de portabilité, donc pas de new(), j'utilise le compilo bcc32, simplement parce que, à priori, il n'y a plus de compilo C avec les environnement Visual Studio ou Borland.

Visual Studio: le compilateur compile du C sans souci. Il y a quelques écarts au standard, mais la doc connait le standard, ceci compense celà. Disons que n'utilisant pas les VLA, je compile sans problème mon code "C99". Ajouter éventuellement ces deux fichiers: stdint.h et inttypes.h.
Sinon, de façon incompréhensible, sur la béta de VS2008, toujours pas de wizard C. Doit être possible de créer un template. Personellement je renomme le .cpp en .c, sinon il faut voir dans les options (C/C++ - Advanced) le commutateur "Compile as", à /TC ou /TP.

Borland: le Turbo C++ "free" propose tous les wizard C qu'on veut, en revanche je n'ai pas regardé la compatibilité dulangage. Le dernier essai C99 de chez Borland m'avait laissé de sales souvenirs, il me semble que je me mets en "compatibilité Borland C++", mais je ne suis pas certain...

[Pierre Maurette]

J'ai un tri QuickSort()... Fonction récursive et je trie de gros fichiers... Autour de 60 Go... Si un fichier est malheureusement déjà trié, la fonction récursive s'empile violemment... Jusqu'à explosé la stack...
Et là, si la programme est compilé avec Visual Studio (), le programme me rend gentiment la main sans exploser ? J'ai bien essayé de regarder autour des stack size... Mais nada...

Jamais été confronté à ce problème, mais il existe. Voyez Google avec des variations autour de:
visual OR VC++ "stack overflow" silently dies
Pour la pertinence votre algo, c'est vous qui voyez...

[Médinoc]

En fait, lors d'un débordement de pile, le programme ne rend pas "gentiment" la main: Il meurt brutalement, comme ça, mais je le reconnais, mystérieusement sans le moindre message.
C'est d'ailleurs comme ça que j'ai appris à reconnaitre cette erreur. Le seul moyen de voir l'exception, c'est d'exécuter le programme dans le debugger.

...Ou de mettre son propre filtre d'exception pour le débordement de pile.


Pour régler le problème, je conseillerais de convertir le quicksort en question en "itératif avec pile", c'est-à-dire utiliser une autre pile que la pile système...

[Gellius31]

Je viens de regarder les pistes de recherche de Pierre par rapport au Stack Overflow... Bien joué, à nouveau, à Pierre...

Donc la solution :
__try {
...
code
...
}
__except(EXCEPTION_EXECUTE_HANDLER) {
...
code
...
}

Cf. l'aide en ligne de Visual Studio 2005 sur __try ou __except.
A ajouter dans la partie de code susceptible de planter, dans mon cas sur l'appel récursif du QuickSort()...

J'ai également vérifier l'impact sur les performances, 14"10' contre 15"49' de tri , soit 12% de plus...