Taille de la pile d'execution
Répondre à la discussion
Affichage des résultats 1 à 9 sur 9

Taille de la pile d'execution



  1. #1
    klark

    Taille de la pile d'execution


    ------

    Bonjour,

    J'ai un programme c++ qui manipule des matrices de grandes tailles.
    Lorsque je compile avec g++, le compilateur ne signale pas d'erreurs. Mais lorsque j'exécute j'ai un message qui me dit :
    terminate called after throwing an instance of 'std::bad_alloc'
    what(): std::bad_alloc
    Abandon (core dumped)

    J'ai diminuer la taille des matrices et la le programme marche. Donc apparemment c un problème dû à la taille de la pile d'exécution.
    Donc comment augmenter cette taille afin que je puisse exécuter le programme.
    J'ai essayer avec ulimit -s mais ca marche pas. la taille reste toujours égale à 10240.

    Merci de votre aide.

    -----

  2. #2
    whoami

    Re : Taille de la pile d'execution

    Bonjour,

    Quand on commence à tomber sur ce genre de problème, au lieu de l'allocation statique (variable déclarée telle quelle, et qui donc se retrouve dans la pile), on utilise l'allocation dynamique de mémoire (eh oui, bonjour les pointeurs).

    Augmenter la taille de la pile d'exécution n'est pas une solution viable, on finit toujours par en atteindre les limites.

  3. #3
    invite251213
    Invité

    Re : Taille de la pile d'execution

    Citation Envoyé par whoami Voir le message
    Quand on commence à tomber sur ce genre de problème, au lieu de l'allocation statique (variable déclarée telle quelle, et qui donc se retrouve dans la pile), on utilise l'allocation dynamique de mémoire (eh oui, bonjour les pointeurs).
    Les variables déclarées telle qu'elles, comme tu dis NE SONT PAS allouées sur la pile. Seules les variables locales le sont.

    Si c'est la pile, c'est surement que tu as imbriqué trop de fonctions les unes dans les autres. Ou que tu as déclaré tes matrices en variables locales au lieu de les passer par pointeur, et là...

    Ou alors le message d'erreur n'a rien à voir avec la pile ou la mémoire.

  4. #4
    whoami

    Re : Taille de la pile d'execution

    Bonjour,

    Je parlais bien entendu des variables locales, quiconque connaît le C avait compris.

  5. A voir en vidéo sur Futura
  6. #5
    bzh_nicolas

    Re : Taille de la pile d'execution

    Tu travailles avec la récursivité ?

  7. #6
    klark

    Re : Taille de la pile d'execution

    Merci à tous. En fait j'utilise la librairie boost pour résoudre un système linéaire.
    Mais je sais pas est ce que l'allocation de mémoire se fait d'une manière dynamique ou pas.

  8. #7
    klark

    Re : Taille de la pile d'execution

    Merci à tous. En fait j'utilise la librairie boost pour résoudre un système linéaire. Toutes les matrices sont des variables globales. Je sais pas est ce qu'il sont stockées dans la pile ou dans la ram, mais ca génère cette exception.

  9. #8
    whoami

    Re : Taille de la pile d'execution

    Bonjour,

    1 - Il faut éviter les variables globales, ça rend le code plus difficilement lisible/maintenable.

    2 - Pour les données nécessitant beaucoup de mémoire, il faut faire l'effort d'utiliser l'allocation dynamique.

  10. #9
    polo974

    Re : Taille de la pile d'execution

    Puisque tu as un core dumped, tu peux aller voir dedans avec gdb ce qu'il s'est passé...
    Quitte à recompiler en gardant les symboles de debug.
    Regarde bien ce qu'il se passe sur la pile (augmentation à chaque appel), tu verras quelle fonction est trop gourmande en variables locales ou si tu as une récursion mortelle.
    Jusqu'ici tout va bien...

Discussions similaires

  1. Comparaison de temps d'execution
    Par invite72c93427 dans le forum Mathématiques du collège et du lycée
    Réponses: 3
    Dernier message: 01/04/2010, 22h23
  2. Probleme d'execution
    Par invite560e37d4 dans le forum Logiciel - Software - Open Source
    Réponses: 1
    Dernier message: 03/10/2009, 13h01
  3. Réponses: 12
    Dernier message: 31/07/2008, 11h52
  4. Réponses: 21
    Dernier message: 28/06/2008, 21h17