problème Mémoire avant appel au main ?

**benhoeil** · 13/10/2006, 10h00

Bonjour,

Il semble que j'ai un problème de mémoire.

voici les extraits du programme qui posent problème :

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
28
29
30
31
#define  MAX_FONCTIONS_UTILISATEURS          50000
 
typedef struct
{
 char*  nom;
 int    nb;
 int    type;
 int    debut;      /* Numero de la ligne ou se trouve l'accolade de debut. */
 int    fin;        /* Numero de la ligne ou se trouve l'accolade de fin : -1 => fonction non trouvee */
 int    nb_appels;  /* Nombre d'appels interessant */
 int    nb_requetes_Sybase;
 int    nb_requetes_Oracle;
 int    nb_chaines_SQL;
} lFU;
 
typedef struct
{
 lFU   liste[MAX_FONCTIONS_UTILISATEURS];
 int   nb_fct_uti;
} FU;
 
...
 
int main(int argc, char** argv)
{
...
 FU          fu;
 
 
...
}

et lorsque je compile, ça passe. Lorsque je lance, ça plante. En utilisant GDB, je m'aperçois que ça plante dès la ligne d'appel du main.

Code :

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

1
2
3
4
5
Program received signal SIGSEGV, Segmentation fault.
0x0040fc63 in probe ()
(gdb) bt
#0  0x0040fc63 in probe ()
#1  0x00401520 in mainCRTStartup () at lister_tables_batch.c:341

en redéfinissant

Code :

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

#define  MAX_FONCTIONS_UTILISATEURS          40000

ça fonctionne.

pourquoi est-ce que cela planterait à 50000 ??? la structure lFu n'est pas si énorme !!

Pour info, je suis sous environnement Cygwin Windows.

**theshark85** · 13/10/2006, 10h04

Car ton Pc a pu assez de memoire pour gerer. Tout simplement, il suffit de regarder avec un ctrl+alt+sup , pour voir approximativement ou en sont tes ressources.

Sinon ta structure n'est pas si enorme que ça, non mais multiplie par MAX_FONCTIONS_UTILISATEURS.

Quand on peut eviter des #define comme celui ci on le fait.

Ne peux tu pas allouer dynamiquement , réagrandir ta structure au fur et a mesure, avec un realloc par exemple?

**DaZumba** · 13/10/2006, 10h05

Envoyé par benhoeil

pourquoi est-ce que cela planterait à 50000 ??? la structure lFu n'est pas si énorme !

Pour la pile, si, elle ne fait souvent guere plus d'un Mo. Et c'est la que resident les tableaux statiquement alloues.

**Franck.H** · 13/10/2006, 10h11

Je crois que si dès le début de l'exécution du programme il se termine en te renvoyant le signal SIGSEGV (qui signifie un accès mémoire invalide), ca veut tout dire ! Le mieux est de faire ca en allocation dynamique qui elle est rangée dans le tas, bien plus gros

**homeostasie** · 13/10/2006, 10h17

Envoyé par Franck.H

Le mieux est de faire ca en allocation dynamique qui elle est rangée dans le tas, bien plus gros

Je pensais que la pile et le tas se partagaient un même espace mémoire. Dans ce "memory pool", le pile croit vers les adresses basses et le tas croit vers les adresses hautes ou inversement.
Avais je donc mal compris ou ca dépendrai de l'implémentation alors?

**Franck.H** · 13/10/2006, 10h26

Envoyé par homeostasie

Je pensais que la pile et le tas se partagaient un même espace mémoire. Dans ce "memory pool", le pile croit vers les adresses basses et le tas croit vers les adresses hautes ou inversement.
Avais je donc mal compris ou ca dépendrai de l'implémentation alors?

Non tu n'as pas mal compris mais le tas est carrément plus gros que la pile. D'après ce que j'ai cru comprendre d'ailleurs, une des limites du tas est celle de la mémoire disponible ... a vérifier !

**Emmanuel Delahaye** · 13/10/2006, 10h34

Envoyé par homeostasie

Je pensais que la pile et le tas se partagaient un même espace mémoire. Dans ce "memory pool", le pile croit vers les adresses basses et le tas croit vers les adresses hautes ou inversement.
Avais je donc mal compris ou ca dépendrai de l'implémentation alors?

Oui. Il y a aussi le cas des piles dont la taille est surveillée, les système avec une pile par thread etc.

**benhoeil** · 13/10/2006, 10h14

mon PC à 2Go de ram, et j'en ai 1,2 Go de libre. Pour moi la réponse de la pile à 1Mo expliquerait tout.
je reprends un programme, et c'est sûr, je dois faire avec...
d'ailleurs, j'ai en commentaire :

/* Limitations : Oui je sais les tableaux dynamiques c'est mieux ... :o) */
/* MAX_NOMS : Mot cles, fonctions systemes et librairies a ne pas traiter */

Merci pour votre aide.

**benhoeil** · 13/10/2006, 10h15

pour la petite histoire, la "pile" doit être beaucoup plus grosse sur les serveurs SUN (je n'en connais pas les détails) puisque la même déclaration à 100000 ne pose aucun problème.

**Franck.H** · 13/10/2006, 10h16

Il faut savoir que la taille de la pile peut varier d'un système à un autre et donc par conséquent ce programme fonctionner sur un système mais peut-être pas sur un autre ... pour moi c'est un gros défaut mais si tu peux changer et le mettre en dynamique tant mieux

**theshark85** · 13/10/2006, 10h18

Et ce n'est pas qu'une question de taille de la pile, ça depend aussi de comment elle est gerer. L'avanatge de l'allocation dynamique est que tu n'auras plus a te soucier du nombre d'utilisateur.
Bon courage.

**Médinoc** · 13/10/2006, 10h27

Ton tableau de 50000 structures est sur la pile, et la pile est très petite.
Si on suppose que tu es sur un système 32bits, chaque structure fait au moins 9*4=36 octets (possiblement 40 si les structures doivent être alignées sur 8 octets).
-->1 800 000 octets, soit 1,71 Mo...

Là, tu as plusieurs solutions possibles:

Déclarer ton tableau en static ou en variable globale, il sera donc dans le segment de données du programme et non dans la pile.
Allouer dynamiquement ton tableau en début de programme: Il sera donc dans le tas et non dans la pile.

**Emmanuel Delahaye** · 13/10/2006, 10h31

Envoyé par benhoeil

Il semble que j'ai un problème de mémoire.

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
#define  MAX_FONCTIONS_UTILISATEURS          50000
 
typedef struct
{
 char*  nom;
 int    nb;
 int    type;
 int    debut;      /* Numero de la ligne ou se trouve l'accolade de debut. */
 int    fin;        /* Numero de la ligne ou se trouve l'accolade de fin : -1 => fonction non trouvee */
 int    nb_appels;  /* Nombre d'appels interessant */
 int    nb_requetes_Sybase;
 int    nb_requetes_Oracle;
 int    nb_chaines_SQL;
} lFU;
 
typedef struct
{
 lFU   liste[MAX_FONCTIONS_UTILISATEURS];
 int   nb_fct_uti;
} FU;
 
int main(int argc, char** argv)
{
 FU          fu;
}

pourquoi est-ce que cela planterait à 50000 ??? la structure lFu n'est pas si énorme !!

Ben si. Tu définis un gros objet en mémoire automatique, çaÿ mal.

La mémoire automatique est une ressource limitée et incontrôlable. La prudence d'impose. Elle est basée sur les 'bonnes pratiques' : au-delà de quelques centaines de char (voire moins en embarqué), pas de mémoire auto.

Soit tu définis l'objet en mémoire statique ('static') -- méthode de chacal, mais ça marche et c'est acceptable si la variable est dans le main(), car quand on est civilisé, on appelle jamais main() --, ou alors en mémoire allouée avec malloc()/free().

**benhoeil** · 13/10/2006, 10h37

je ne me suis jamais posé la question de l'endroit ou était stockées les variables en fait. Là j'en apprend bcp d'un coup (sans forcément comprendre):
pile ?
tas ?

**Médinoc** · 13/10/2006, 10h44

Ça, c'est ce qu'on nous apprenait en premier sur les programmes informatiques.
Un programme chargé est composé de 4 zones mémoire:

Code: Le code exécutable du programme. En théorie, c'est la seule zone où le processeur peut exécuter du code.
Données: Les données statiques du programme. C'est là que sont toutes les variables globales et les variables locales static. Dans les deux cas, il n'existe qu'un exemplaire de chaque par processus, une variable locale static est donc l'équivalent d'une variable globale.
Pile: La zone où se trouvent les variables "automatiques" du programme, c'est-à-dire les variables locales non-statiques de chaque fonction. Une variable est empilée sur la pile au début de bloc où elle est déclarée et détruite en fin de bloc. Et comme son nom l'indique, les variables locales des différentes fonctions sont empilées à mesure que les fonctions appellent d'autres fonctions, et sont dépilées quand les fonctions retournent.
Tas: Une zone souvent limitée uniquement par la mémoire disponible. C'est là où tapent les malloc().

**homeostasie** · 13/10/2006, 10h56

Il y a aussi la zone bss comprise dans le "system image" (text+data+bss). Je crois que le segment bss comprends les variables globales non initialisées.

**Emmanuel Delahaye** · 13/10/2006, 11h07

Envoyé par homeostasie

Il y a aussi la zone bss comprise dans le "system image" (text+data+bss). Je crois que le segment bss comprends les variables globales non initialisées.

Détails d'implémentation. Merci de ne pas mélanger les différents niveaux d'abstraction.

**Emmanuel Delahaye** · 13/10/2006, 10h48

Envoyé par benhoeil

je ne me suis jamais posé la question de l'endroit ou était stockées les variables en fait. Là j'en apprend bcp d'un coup (sans forcément comprendre):
pile ?
tas ?

http://emmanuel-delahaye.developpez....s.htm#pile_tas

Et hop !

problème Mémoire avant appel au main ?

C

Vue hybride

Discussions similaires

Partager

Partager