Problème allocation mémoire - malloc () 1Gb

Version imprimable

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:

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

19/12/2007, 17h12
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 ?
19/12/2007, 20h35
souviron34

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

A mon avis y aurait comme un petit probleme de conception.....
19/12/2007, 23h12
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 ???
20/12/2007, 05h26
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 .. :roll:
20/12/2007, 09h07
Pierre Maurette

Citation:

Envoyé par 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...

C'est donc que vous n'appelez pas le "bon" malloc() :lol:
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.

Citation:

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.
20/12/2007, 09h27
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 ?
20/12/2007, 09h30
Pierre Maurette

Citation:

Envoyé par 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 ?

Projet / Options / Lieur / Liaison / Utiliser la RTL dynamique ?
20/12/2007, 09h47
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 !
20/12/2007, 09h49
Gellius31

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

Many thanks.
20/12/2007, 09h56
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...
20/12/2007, 10h13
Pierre Maurette

Citation:

Envoyé par Gellius31

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...
20/12/2007, 10h34
Pierre Maurette

Citation:

Envoyé par Gellius31

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...
20/12/2007, 11h47
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...
21/12/2007, 12h16
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...