Question sur les problèmes d'allocation dynamique

Version imprimable

21/10/2004, 16h59
slylafone

Question sur les problèmes d'allocation dynamique

Bonjour,

Une question me trotte dans la tête depuis un moment.
Je lis souvent qu'une allocation dynamique peut échouer.

Perso, je prends toujours pour hypothèse que tout se passera bien (sauf si je veux une "grosse" zone mémoire). En tout cas, je n'ai jamais constaté ce genre de problème dans mes programmes.

Je pense que ça devient vite ingérable si il faut controler à chaque fois. En plus, on aura tendance dans ce cas à faire une sur-utilisation de la pile (dites-moi si je dis n'importe quoi :wink: ).

Quand faut-il faire une vérification et pourquoi ?

Merci,
Sly.
21/10/2004, 17h36
Luc Hermitte

Quand ? il faut toujours se préoccuper de ces problèmes. (je ne dis pas "vérifier le succès des allocations"!)

Pourquoi ? Murphy veille. Et si jamais un tel problème survient à un endroit où l'on ne pensait pas qu'il surviendrait, on va perdre un temps fou à le retrouver. C'est le genre de problème qui ne survient pas jusqu'au jour où l'on en constate les symptômes. Et puis une application qui crashe n'est jamais beau à voir ; et une qui perd ses ressources ne fais absolument pas sérieux (surtout si elle doit tourner 24h sur 24).

La Pile ? Même genre de problème, à la différence que l'on ne peut pas allouer des zones dont on ne connait pas la taille à la compilation, et au détail qu'un échec d'allocation est non rattrapable.

Comment s'en sortir ? L'idiome RAII est notre ami. Cela signifie envelopper nos ressources dans des objets automatiques comme des smart-pointers ou des vecteurs dans le cas de zones mémoire. Avec ça, je n'ai pas à contrôler chaque allocation de ressource, c'est transparent, à commencer par la désallocation.

Lecture intéressante :
- GOTW : items sur l'exception safety
- Cours C++
21/10/2004, 17h42
r0d

Citation:

Envoyé par Luc Hermitte

envelopper nos ressources dans des objets automatiques comme des smart-pointers ou des vecteurs dans le cas de zones mémoire.

Mais (arêtez-moi de suite si je dis une connerie) c'est pas du tout portable ça non?
21/10/2004, 18h06
Laurent Gomila

Citation:

(arêtez-moi de suite si je dis une connerie)

Stoooooop !!! :lol:

Les différentes classes de pointeurs intelligents que tu pourras trouver seront toutes portables a priori, puisque c'est un concept qui ne requiert aucun code spécifique au système, on peut tout coder en C++ standard.

Quant aux vecteurs et autres, ils font partie de la bibliothèque standard, donc la question ne se pose pas.
21/10/2004, 18h06
ShootDX
C'est portable! C'est un système d'encapsulation, qu'on peut très bien faire soit même (ici je retire les templates pour faire plus lisible):
Code:

1 2 3 4 5 6 7 class smart_ptr { int *p_; public: smart_ptr() { p = new int; } ~smart_ptr() { delete p_; } ... };
21/10/2004, 18h46
r0d

okay :oops: désolé

et donc, si je comprends bien, l'avantage des smart pointers c'est qu'on peut ainsi faire les vérifications necessaires des qu'il y a allocation de mémoire? Ce serait une sorte de factorisation de code: au lieu de vérifier à chaque fois qu'on fait un new machin(), on vérifie dans le new machin(). C'est ça?
21/10/2004, 18h56
Luc Hermitte

Non, on ne vérifie rien à ce niveau -- cela sera fait à un niveau qui a du sens par rapport à l'application. Cela sert si une opération échoue après une allocation, la ressource allouée sera alors automatique rendue, vu que l'échec aura détourné le flot de l'exécution (par exception ou retour anticipé).

Prend du temps et lis le chapitre du C++ in Action. Puis le reste.

(On ne teste le résultat de new qu'avec les compilos qui ne respectent pas le standard : genre VC 6.x ; ceci dit, il me semble que <new> permet de restorer le comportement standard, qui est de lever une exception)
21/10/2004, 21h14
slylafone

Merci pour vos réponses.

J'utilise les SmartPtr et les ScopeGuards.
Mais je les utilise en réponse aux exceptions.
Je ne les utilise pas en pensant à un problème d'allocation dynamique.

En gros, si j'ai ce genre de problème, je ne sais pas du tout comment réagira mon programme. Et puis il faudrait faire des try/catch un peu partout et mettre en place un mécanisme de transaction. Ca complique tout. C'est déjà assez difficile de bien gérer toutes les autres exceptions.
Finalement, est ce que ça en vaut vraiment la peine ?

Citation:

C'est le genre de problème qui ne survient pas jusqu'au jour où l'on en constate les symptômes.

Quels types de symptômes ?

Citation:

La Pile ? Même genre de problème, à la différence que l'on ne peut pas allouer des zones dont on ne connait pas la taille à la compilation, et au détail qu'un échec d'allocation est non rattrapable.

Exactement!
Donc si on ne peut rien faire au niveau de la pile, c'est un peu de la poudre aux yeux de prendre en compte le tas. (j'en rajoute un peu :wink:)

Sly.
21/10/2004, 22h40
JolyLoic

Citation:

Envoyé par slylafone

J'utilise les SmartPtr et les ScopeGuards.
Mais je les utilise en réponse aux exceptions.
Je ne les utilise pas en pensant à un problème d'allocation dynamique.

Sauf que c'est pareil : Quand une allocation dynamique échoue, elle lance une exception... Sauf comme l'a dit Luc avec certains vieux compilos.
21/10/2004, 23h32
Aurelien.Regat-Barrel

Je crois que ce qu'il se demande c'est comment gérer ça en pratique. Si a chaque fois que tu fais un push_back tu dois mettre ça dans un bloc try...catch tu t'en sors plus.
22/10/2004, 09h24
slylafone

Citation:

Je crois que ce qu'il se demande c'est comment gérer ça en pratique. Si a chaque fois que tu fais un push_back tu dois mettre ça dans un bloc try...catch tu t'en sors plus.

Exactement !
Prenons un cas pratique : Un programme reçoit une liste d'objet qu'il doit insérer dans une base de donnée. Pour garantir l'insertion, on stocke ces objets dans un objet std::queue par exemple avant de tenter de les insérer dans la base de donnée.

Oui mais std::queue peut déclencher une exception en cas de problème d'allocation dynamique. Donc je ne peux pas vraiment garantir le résultat.
Dans ce cas, je suppose qu'il n'y aura pas de problème à ce niveau, sinon je ne m'en sort pas!
22/10/2004, 10h40
Luc Hermitte

Tu définis donc un scope guard dont le rôle est de faire un rollback (c'est bien donc ça que l'on dit ?) (=> 0 capture à ce niveau) ; et dans un des appelants, tu captureras l'exception pour signaler à l'utilisateur que ce qu'il a voulu faire n'a pas été validé.

Ce qu'il faut garantir, c'est le côté transactionnel des opérations => si il y a un échec, alors l'état du systême doit demeurer inchangé.

Pour ce qui est des symptômes, c'est le seul terme qui me venait à l'esprit pour désigner : comportement étrange de l'application et pertes de ressources (fichiers, handles de X ou Y, pots de peintures, mémoire, ...)
22/10/2004, 11h05
slylafone

Ok merci pour la réponse.
Je comprends bien.

Mais encore 2 questions :
- Est ce que ce n'est pas en faire un peu trop, sachant que je n'ai jamais constaté ce type de problème ?
- Si l'action n'est pas déclenchée par un utilisateur mais par un périphérique, comment je peux faire pour vraiment garantir l'insertion (sachant que je ne peux pas demander au périphérique qu'il me renvoit les données).
22/10/2004, 11h17
Luc Hermitte

Tu n'as jamais eu ce problème ... mais si il venait à survenir, tu aurais beaucoup de choses à reprendre.
Et puis rien ne garanti que le client qui fera tourner l'application le fera dans les meilleures conditions.

Ensuite, mais qu'est-ce qui est vraiment important à garantir ? L'insertion d'un pour-cent des données ? Leur perte ou la corruption de la base ?

Citation:

Envoyé par slylafone

Ok merci pour la réponse.
Je comprends bien.

Mais encore 2 questions :
- Est ce que ce n'est pas en faire un peu trop, sachant que je n'ai jamais constaté ce type de problème ?
- Si l'action n'est pas déclenchée par un utilisateur mais par un périphérique, comment je peux faire pour vraiment garantir l'insertion (sachant que je ne peux pas demander au périphérique qu'il me renvoit les données).

1/ Je pense qu'il faut distinguer 2 choses :
protéger une partie de code qui est sensible à une exception
gérer les erreurs dans l'ensemble de l'appli.
Typiquement, si tu te prends un exception tu dois, localement, faire en sorte de ne pas te retrouver dans un état invalide. Par exemple, lors de plusieurs allocation, la dernière échoue, l'exception remonte et tu provoques des fuites de mémoire. Ou le cas de luc : synchronisation entre tes structures en mémoire et une bd, si une est mise à jour et pas l'autre, oups, probleme.
Soit ta fonction, si son appel échoue par manque de mémoire, il te faut faire en sorte que l'on puisse la rappeler quelques secondes après (une fois la mémoire dispo) pour fonctionner correctement. Ca c'est la gestion locale des erreurs.
Apres, ta fonction laisse remonter des exceptions et tu t'es ainsi assuré que tu quittes la fontion dans un état cohérent. Au niveau de l'appli il faut maintenant gérer toutes ces exceptions qui peuvent remonter. Plus tu gère ça en amont (par exemple dans la fonction main() ) et plus c'est facile.
Exemple :
Tu as 10 fonctions qui font chacune un calcul. Dans ton main tu affiches un menu qui permet d'appeler une fonction au choix. Tu peux mettre ton gestionnaire de bad_alloc dans le main():
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 int main() { while ( true ) { AfficheMenu(); char choix; cin >> choix; if ( choix == 'q' ) break; try { AppelleFonction( choix ); } catch ( const std::bad_alloc & ) { std::cerr << "Impossible d'effectuer le traitement : mémoire insuffidante\n"; } } }
Dans chaque fonction tu dois t'assurer qu'une exception ne provoque pas des fuites de mémoires, des fichiers non fermés, etc... Mais t'es pas obligé de pourir ton code de try...catch pour autant. Pour peu que tu utilises des objects automatiques, des smart pointers, des scope guards, ton code est exception safe sans avoir un seul bloc try...catch.
Comme tu vois gérer ces exceptions n'est pas très compliqué, et ça donne une bonne image à ton appli. Il m'arrive de temps en temps, lorsque j'ai la émoire saturée, de lancer des applis en me demandant comment elles vont réagir. Je ne leur en veut pas de se vautrer (quoique si c'est des applis commerciales chères), mais si elles gèrent ça bien c'est très bien perçu.
Bon cela dit avec une IHM c'est un peu moins évident.

2/ insertion de quoi ? Comment ça un périph qui déclenche une action ?

22/10/2004, 18h13
slylafone

Merci beaucoup pour cette jolie explication.:ccool:

Citation:

Il m'arrive de temps en temps, lorsque j'ai la émoire saturée, de lancer des applis en me demandant comment elles vont réagir. Je ne leur en veut pas de se vautrer

Mais dans ce cas, même si la mémoire est saturée, l'OS est capable de faire un swap sur le disque pour libérer de la mémoire, non ?

Citation:

Bon cela dit avec une IHM c'est un peu moins évident.

Cette remarque me fait chaud au coeur. Je trouve aussi.

Je comprends bien la théorie, et Luc m'avait déjà bien orienté à ce sujet en me présentant les ScopeGuards. Je lui en suis très reconnaissant, car dans la foulé, je me suis mis à m'interessé et à pratiqué ce genre de technique. (i.e. l'idiome RAII).

Actuellement, je met à jour des anciens programmes (pas de moi) et parrallelement je développe de nouveaux programmes. L'ancien programmeur ne sait jamais soucié de faire des ScopeGuards ou d'utiliser des SmartPtr ni même de gérer les exceptions, et pourtant ses programmes sont réputés très robustes.

En pratique, protéger une partie de code qui est sensible à une exception ne demande pas forcement du temps (et c'est très bien de le faire), mais faire une bonne gestion des erreurs avec une IHM complexe c'est autre chose je trouve (ça multipli les try/catch). C'est pour ça que je me demande jusqu'où il faut aller... car j'ai déjà pas mal de boulot avec la gestion des erreurs aux accès BD par exemple.

Citation:

insertion de quoi ? Comment ça un périph qui déclenche une action ?

En fait, j'ai un périphérique externe qui envoit des informations sur le port série. Ces informations doivent être affichées et sauvegardées dans la base de données. Mon programme ne doit surtout pas en perdre !
22/10/2004, 18h51
Aurelien.Regat-Barrel

Citation:

Mais dans ce cas, même si la mémoire est saturée, l'OS est capable de faire un swap sur le disque pour libérer de la mémoire, non ?

Mémoire au sens mémoire virtuelle. Le swap aussi peut arriver à satturation... surtout quand il est désactivé comme chez moi :lol:

Citation:

En fait, j'ai un périphérique externe qui envoit des informations sur le port série. Ces informations doivent être affichées et sauvegardées dans la base de données. Mon programme ne doit surtout pas en perdre !

Ben si ta BD ne veut plus écrire tu peux pas faire grand chose.
22/10/2004, 20h28
Luc Hermitte

Je pense qu'il faut distinguer les types d'erreurs et leurs gravités respectives. Toutes ne se traitent pas de la même façon. Genre la situation extrême où il devient impossible de sauvegarder ce qui arrive sur le flux entrant. Mieux vaut s'arréter proprement que de planter parce que ce cas n'avait pas été envisagé.

Après, si le moteur est bien découpé de l'IHM, je ne vois pas trop en quoi celle-ci complique plus le traitement des exceptions (si on excepte les risques qu'une exception se produise au niveau IHM alors que l'on en traite déjà une)

Pour la robustesse, j'ai envie de dire que cela concerne deux choses : les codeurs qui n'introduisent pas de bugs (potentiellement maitrisable), et les situations contre lesquelles on ne peut rien faire (mémoire saturée, disque saturé (ce qui m'arrive de temps à autres) ou défectueux, connection au périphérique rompue, ...)

(Sinon, je me demandais dans quel enfer on se trouvait quand la mémoire devenait "insuffidante" ... :P)
22/10/2004, 22h19
Aurelien.Regat-Barrel

Citation:

Envoyé par Luc Hermitte

Après, si le moteur est bien découpé de l'IHM, je ne vois pas trop en quoi celle-ci complique plus le traitement des exceptions (si on excepte les risques qu'une exception se produise au niveau IHM alors que l'on en traite déjà une)

Justement, c'est parce que le moteur est bien découpé que c'est galère. Tu as des dizaines de "connexions" entre le moteur et l'IHM (typiquement le code de gestion d'un clic de bouton appelle une fontion du moteur = une connexion). A chaque connexion il faut un bloc try...catch... T'es facilement tenté de laisser passer le bad_alloc.

Ce n'est pas un problème.
C'est encore un endroit où l'on peut utiliser des macros, ou carrément des fonctions

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
template <typename F>
void run_and_catch(F f)
{
    std::string message;
    try {
        f();
    } catch(std::bad_alloc &) {
        message = "mémoire insuffisante";
    } catch(my::except_Z &e) {
        message = "problème Z survenu" + e.what();
    } ...
    } catch(std::exception &e) {
        message = "problème: " + e.what();
    }
    App->ErrorBox(message);
}
 
....
    run_and_catch(boost::bind(obj,fn,p1,p2));

Bon évidemment, cela suppose que pour un type d'exception donné, le message à afficher ne doivent pas trop changer.

Ah... j'avais pas pensé à une fonction template, et je connaissais pas boost::bind. Du coup j'ai utilisé à contre coeur des macros. Surtout que je vois parfaitement où je pourrais caser ça. J'ai une classe error manager que j'utilise ainsi :

Code:

1
2
3
4
5
6
7
 
void MyDlg::buttonStartClicked()
{
    TRY_EM( "MyDlg::buttonStartClicked()" )
        this->Model.Start();
    CATCH_EM
}

Ces macros valent en gros :

Code:

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
32
33
34
35
36
37
38
39
40
 
#define TRY_EM( name ) \
    {\
    ErrorManager em( name ); \
    try \
    {\    
 
#ifdef DEBUG
#define CATCH_EM \
    }\
    catch ( const UserException & e )\
    {\
        em.Error( e );\
    }\
    }
#else
#define CATCH_EM \
    }\
    catch ( const UserException & e )\
    {\
        em.Error( e );\
    }\
    catch ( const InternalException & e )\
    {\
        em.Error( e );\
    }\
    catch ( const std::bad_alloc & e )\
    {\
        em.Error( e );\
    }\
    catch ( const std::exception & e )\
    {\
        em.Error( e );\
    }\
    catch ( ... )\
    {\
        em.CriticalError();\
    }\
    }
#endif

En debug seules les erreurs destinnéées à l'utilisateur sont traitées, le reste c'est des erreurs internes (assertion maison qui foire, division par zero, etc...) et je les traite pas pourque le debugger m'y emène.

Avec un zoli template, ca deviendrait :

Code:

1
2
3
4
5
6
7
 
void MyDlg::buttonStartClicked()
{
    ErrorManager em( "MyDlg::buttonStartClicked()" );
    em.SafeCall(
        this->Model.Start );
}

23/10/2004, 17h49
Luc Hermitte

Si tu appelles toujours exactement "em.Error(e);", et que la fonction n'a pas été surchargée, alors il est encore plus simple de faire dériver tout le monde de std::exception.

Sinon, j'ai au contraire encore plus d'exceptions à afficher en mode debug. J'utilise des smart-assertions, inspirées de l'article d'Andrei Alexandrescu, qui peuvent lever des exceptions.

PS: pour boost::bind, je n'ai pas vérifier mais il me semble que l'écriture que j'ai utilisée définit un foncteur qui sera évalué en "obj.fn(p1,p2);" -- j'ai un doute dans l'ordre des paramètres.
23/10/2004, 23h21
Aurelien.Regat-Barrel

Citation:

Envoyé par Luc Hermitte

Si tu appelles toujours exactement "em.Error(e);", et que la fonction n'a pas été surchargée, alors il est encore plus simple de faire dériver tout le monde de std::exception.

Elle est surchargée, et mes classes perso d'exception héritent de std::exception. Cependant elles me donnent plus d'infos : lieu de l'exception, parametre invalide, message d'aide pour l'utilisateur, etc...

Citation:

Envoyé par Luc Hermitte

Sinon, j'ai au contraire encore plus d'exceptions à afficher en mode debug. J'utilise des smart-assertions, inspirées de l'article d'Andrei Alexandrescu, qui peuvent lever des exceptions.

Ben moi je les affiche pas. En ne les catchant pas, le debugger de VS me place à l'endroit exact où elle a lieu, je peux voir en live la valeur des variables, la pile des appels, etc...
25/10/2004, 14h18
slylafone

Merci beaucoup pour les infos et les idées.
Il va falloir que je me penche sur la librairie boost. Ca a l'air interessant.