Gestion de mémoire en C++ ----> conséquences
Fermé
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
-
1 oct. 2008 à 10:41
little_titi Messages postés 242 Date d'inscription lundi 31 mars 2008 Statut Membre Dernière intervention 23 novembre 2009 - 6 oct. 2008 à 14:27
little_titi Messages postés 242 Date d'inscription lundi 31 mars 2008 Statut Membre Dernière intervention 23 novembre 2009 - 6 oct. 2008 à 14:27
A voir également:
- Gestion de mémoire en C++ ----> conséquences
- Logiciel gestion photos - Guide
- Mémoire virtuelle - Guide
- Tfc informatique de gestion g3 pdf - Forum Bases de données
- Mémoire vidéo dédiée : 128 mo ✓ - Forum Carte graphique
- Exemple de thème de mémoire en secrétariat - Forum Mail
11 réponses
Utilisateur anonyme
2 oct. 2008 à 21:07
2 oct. 2008 à 21:07
Bonjour,
Je me permet quelques observations étant assez calé dans le domaine en toute humilité.
J'ai eu à m'occupper d'un parc de 30 PCs qui utilisait un gros logiciel dont 300 utilisateurs
au total se connectait. Les utilisateurs avait ce genre de problèmes à raison de 2 a 3 fois par jour.
(30 utilisateurs * 2/jrs ) * 5jrs = 300 plantages par semaine.
Après une analyse de la configuration des postes, quincaillerie et logiciels, j'ai remanié le tout
à ma façon et après avoir fait le tour du parc de 30 poste, j'avais réduit le platage globale
par semaine à 5 ou 6 fois max pour l'ensemble des utilisateurs.
Point à observer :
Le poste est-il redémarrer à tous les jours ?
Le poste est-il défragmenter à toutes les semaines ?
Un scandisk est-il effectué à toutes les semaines ?
La séquence d'installation est-elle optimiser ?
L'application est-elle trop lourde pour la génération du poste ?
N'oublie jamais que Windows se tue de lui-même, et si tu as des doutes, ouvre
ton poste et n'y touche pas pendant un mois, tu m'en donneras des nouvelles.
Le redémarrage est essentiel ainsi que le vidage du swapfile à chaque fois pour
une bonne optimisation des ressources.
Le problème que tu présente me semble lier à ce genre de situation.
Quoi qu'il en soit, j'ai eu à me battre pendant un an avec des spécialistes
pour démontrer cette situation et quand j'ai eu fini le tour de mon parc
de 30 usagers, ils sont venu cherché ma façon de faire !
Lupin
Je me permet quelques observations étant assez calé dans le domaine en toute humilité.
J'ai eu à m'occupper d'un parc de 30 PCs qui utilisait un gros logiciel dont 300 utilisateurs
au total se connectait. Les utilisateurs avait ce genre de problèmes à raison de 2 a 3 fois par jour.
(30 utilisateurs * 2/jrs ) * 5jrs = 300 plantages par semaine.
Après une analyse de la configuration des postes, quincaillerie et logiciels, j'ai remanié le tout
à ma façon et après avoir fait le tour du parc de 30 poste, j'avais réduit le platage globale
par semaine à 5 ou 6 fois max pour l'ensemble des utilisateurs.
Point à observer :
Le poste est-il redémarrer à tous les jours ?
Le poste est-il défragmenter à toutes les semaines ?
Un scandisk est-il effectué à toutes les semaines ?
La séquence d'installation est-elle optimiser ?
L'application est-elle trop lourde pour la génération du poste ?
N'oublie jamais que Windows se tue de lui-même, et si tu as des doutes, ouvre
ton poste et n'y touche pas pendant un mois, tu m'en donneras des nouvelles.
Le redémarrage est essentiel ainsi que le vidage du swapfile à chaque fois pour
une bonne optimisation des ressources.
Le problème que tu présente me semble lier à ce genre de situation.
Quoi qu'il en soit, j'ai eu à me battre pendant un an avec des spécialistes
pour démontrer cette situation et quand j'ai eu fini le tour de mon parc
de 30 usagers, ils sont venu cherché ma façon de faire !
Lupin
Marco la baraque
Messages postés
996
Date d'inscription
vendredi 9 mai 2008
Statut
Contributeur
Dernière intervention
5 novembre 2009
328
1 oct. 2008 à 15:14
1 oct. 2008 à 15:14
Bonjour little_titi,
Je ne suis pas un expert en C++ (loin de là d'ailleurs). Je pense que les problèmes de gestion mémoire dont tu parlent sont présents quelque soit le langage utilisé, c'est un aspect assez bas niveau en fait.
Certains langages ne laissent pas l'utilisateur faire des optimisations mémoire, d'autre si, mais pour bien programmer, dans tous les cas, l'idéal est d'avoir ces connaissances afin d'optimiser un maximum le code.
Concrètement, selon moi, les différents cas qui peuvent se produire lors d'une "mauvaise gestion de la mémoire":
- le segfault: tu essaies d'écrire dans une zone qui n'est pas allouée, ou sur laquelle tu n'as pas de droit, souvent à cause d'un buffer overflow. Résultat : ton application crashe et revient à windows
- le stack overflow: tu empiles, tu empiles, et au final tu dépasses la taille de ta mémoire vive (ça arrive souvent quand tu as une boucle infinie involontaire). Sous windows je ne sais pas ce que ça fait, mais à mon avis soit ton programme est killé, soit tu as un écran bleu
- le multi-tâche. Ici on ne parle pas trop de programmation. L'idée est de comprendre que chaque process occupe un espace alloué en mémoire vive. Il peut y avoir des problèmes de fragmentation qui vont ralentir les accès à l'information, et donc ralentir un petit peu tes programmes, mais il faudrait avoir l'avis d'un admin système pour avoir des métriques. Là où le multitâche est problématique, c'est lorsque tes process ouverts occupent un espace mémoire supérieur à ta capacité. Dans ce cas, une partie de ces ressources est stockée sur le disque dur (swapping), et dès que l'ordonnanceur donne la main au process concerné, les données contenues sur le disque dur sont déplacés en mémoire, et des données en mémoire qui ne sont plus utilisées sont placées sur le disque dur. Ce swapping est extrêmement coûteux en terme de temps, parce que l'accès au disque dur, c'est long ! Il n'y a pas forcément de solution miracle pour ce problème, mais il faut simplement comprendre que si ton application occupe un espace mémoire de 100Mo et que tu as juste une 128Mo de Ram, ton appli risque de ramer un max, parce que ton système va swapper des infos en continu. D'où le fait qu'il faut que tu optimises ton code un max afin de minimiser la durée de vie de tes variables/objets/tout ce que tu veux, afin de consommer un minimum de ressources.
Pour l'écran freezé, selon moi, ce n'est pas un problème de gestion mémoire. Tu vas avoir ce genre de problème si tu as une boucle infinie par exemple : le programme va tourner tourner tourner, faire des calculs dans tous les sens sans jamais s'arrêter; et à un moment l'ordonnanceur va te dire "oulala, ce process n'a pas l'air d'aller bien, tu ne veux pas l'arrêter là ?", mais je ne pense pas que ça vienne de la mémoire.
Cordialement,
Je ne suis pas un expert en C++ (loin de là d'ailleurs). Je pense que les problèmes de gestion mémoire dont tu parlent sont présents quelque soit le langage utilisé, c'est un aspect assez bas niveau en fait.
Certains langages ne laissent pas l'utilisateur faire des optimisations mémoire, d'autre si, mais pour bien programmer, dans tous les cas, l'idéal est d'avoir ces connaissances afin d'optimiser un maximum le code.
Concrètement, selon moi, les différents cas qui peuvent se produire lors d'une "mauvaise gestion de la mémoire":
- le segfault: tu essaies d'écrire dans une zone qui n'est pas allouée, ou sur laquelle tu n'as pas de droit, souvent à cause d'un buffer overflow. Résultat : ton application crashe et revient à windows
- le stack overflow: tu empiles, tu empiles, et au final tu dépasses la taille de ta mémoire vive (ça arrive souvent quand tu as une boucle infinie involontaire). Sous windows je ne sais pas ce que ça fait, mais à mon avis soit ton programme est killé, soit tu as un écran bleu
- le multi-tâche. Ici on ne parle pas trop de programmation. L'idée est de comprendre que chaque process occupe un espace alloué en mémoire vive. Il peut y avoir des problèmes de fragmentation qui vont ralentir les accès à l'information, et donc ralentir un petit peu tes programmes, mais il faudrait avoir l'avis d'un admin système pour avoir des métriques. Là où le multitâche est problématique, c'est lorsque tes process ouverts occupent un espace mémoire supérieur à ta capacité. Dans ce cas, une partie de ces ressources est stockée sur le disque dur (swapping), et dès que l'ordonnanceur donne la main au process concerné, les données contenues sur le disque dur sont déplacés en mémoire, et des données en mémoire qui ne sont plus utilisées sont placées sur le disque dur. Ce swapping est extrêmement coûteux en terme de temps, parce que l'accès au disque dur, c'est long ! Il n'y a pas forcément de solution miracle pour ce problème, mais il faut simplement comprendre que si ton application occupe un espace mémoire de 100Mo et que tu as juste une 128Mo de Ram, ton appli risque de ramer un max, parce que ton système va swapper des infos en continu. D'où le fait qu'il faut que tu optimises ton code un max afin de minimiser la durée de vie de tes variables/objets/tout ce que tu veux, afin de consommer un minimum de ressources.
Pour l'écran freezé, selon moi, ce n'est pas un problème de gestion mémoire. Tu vas avoir ce genre de problème si tu as une boucle infinie par exemple : le programme va tourner tourner tourner, faire des calculs dans tous les sens sans jamais s'arrêter; et à un moment l'ordonnanceur va te dire "oulala, ce process n'a pas l'air d'aller bien, tu ne veux pas l'arrêter là ?", mais je ne pense pas que ça vienne de la mémoire.
Cordialement,
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
1 oct. 2008 à 15:46
1 oct. 2008 à 15:46
Merci pour cette réponse et toutes ces explications détaillées!!! J'ai appris beaucoup de choses! ;) Je vais essayé de voir alors.
Mais pas évident car le programme de l'appli ce n'est pas moi qui l'ait conçu et pour repérer une boucle infinie dans tous ces fichiers qu'elle comporte...aie!
Pour faire bref, j'ai des histoires d'ouvertures de sessions via une carte à puce et des enregistrements constant sur une autre carte à puce. En fait on se logue avec une carte, et ensuite on bosse sur l'appli en enregistrant sur une autre carte les opérations que l'on réalise. Le pbm c'est que l'appli bloque pas toujours mais régulièrement quand même (1 fois par semaine) et lorsqu'on redémarre l'appli on ne peut plus utiliser la première carte qui a servi à se loguer, on doit obligatoirement ouvrir avec une autre carte (une autre session en quelque sorte...).
voila en gros mon principal souci. C'est pour ça que je me posais ces questions.
Mais pas évident car le programme de l'appli ce n'est pas moi qui l'ait conçu et pour repérer une boucle infinie dans tous ces fichiers qu'elle comporte...aie!
Pour faire bref, j'ai des histoires d'ouvertures de sessions via une carte à puce et des enregistrements constant sur une autre carte à puce. En fait on se logue avec une carte, et ensuite on bosse sur l'appli en enregistrant sur une autre carte les opérations que l'on réalise. Le pbm c'est que l'appli bloque pas toujours mais régulièrement quand même (1 fois par semaine) et lorsqu'on redémarre l'appli on ne peut plus utiliser la première carte qui a servi à se loguer, on doit obligatoirement ouvrir avec une autre carte (une autre session en quelque sorte...).
voila en gros mon principal souci. C'est pour ça que je me posais ces questions.
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
1 oct. 2008 à 16:52
1 oct. 2008 à 16:52
De toute façon problème mémoire ou pas, ça viens du code source, et si tu veux le résoudre, il faut mettre les mains dedans.
Il est peut être aussi possible que le problème vienne de l'interface avec le périphérique de lecture de carte et non du logiciel.
Je citerai une autre erreur de gestion de mémoire: l'écriture dans un endroit non attendu : comme le "buffer overflow" tu dépasse la taille d'un tableau, mais tu écris dans une zone mémoire appartenant au programme modifiant une autre donnée.
Il existe différentes méthodes pour trouver où se cache les erreurs, les debuggeurs (gdb) et les analyseurs de programme (valgrind)
Il est peut être aussi possible que le problème vienne de l'interface avec le périphérique de lecture de carte et non du logiciel.
Je citerai une autre erreur de gestion de mémoire: l'écriture dans un endroit non attendu : comme le "buffer overflow" tu dépasse la taille d'un tableau, mais tu écris dans une zone mémoire appartenant au programme modifiant une autre donnée.
Il existe différentes méthodes pour trouver où se cache les erreurs, les debuggeurs (gdb) et les analyseurs de programme (valgrind)
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
1 oct. 2008 à 17:40
1 oct. 2008 à 17:40
O fait est ce que Valgrind est utilisable sous windows en ligne de commande ? car j'ai l'impression que c'est surtout pour linux...et j'ai pas Linux installé sur cette machine!!! lol
Merci
Merci
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
1 oct. 2008 à 17:05
1 oct. 2008 à 17:05
salut!
ben justement je suis dans le code!!! et à vrai dire un pbm d'interface avec le periphérique (le lecteur de carte par exemple) c'est vrai que ma foi j'avais pas pensé!pourquoi pas...
Je connais les débug mais pa les valgrind...ça marche comment??
Merci les gars!
ben justement je suis dans le code!!! et à vrai dire un pbm d'interface avec le periphérique (le lecteur de carte par exemple) c'est vrai que ma foi j'avais pas pensé!pourquoi pas...
Je connais les débug mais pa les valgrind...ça marche comment??
Merci les gars!
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
1 oct. 2008 à 17:30
1 oct. 2008 à 17:30
je regarde comment marche valgrind... En tout cas merci pour l'info "Char Snipeur"!!! ;)
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
2 oct. 2008 à 08:34
2 oct. 2008 à 08:34
En effet, après un petit tour sur Wikipedia, il semble qu'il n'y ai pas de version pour MS (ce qui se comprends étant donné la différence entre les OS et la nature du programme).
par contre, en cliquant sur les outils similaire j'ai trouvé ça :
https://en.wikipedia.org/wiki/Memory_debugger
à toi de fureter dedans pour trouver ce qui te conviens le mieux.
par contre, en cliquant sur les outils similaire j'ai trouvé ça :
https://en.wikipedia.org/wiki/Memory_debugger
à toi de fureter dedans pour trouver ce qui te conviens le mieux.
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
2 oct. 2008 à 11:20
2 oct. 2008 à 11:20
Merci pour le lien j'épluche ça! ;)
jihelge
Messages postés
71
Date d'inscription
mardi 5 février 2008
Statut
Membre
Dernière intervention
4 octobre 2008
7
>
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
2 oct. 2008 à 11:34
2 oct. 2008 à 11:34
Bonjour Little_titi,
En C++ (comme dans beaucoup de langage quand on utilise de l'allocation dynamique de ressources) l'instanciation d'objet est une demande d'allocation de mémoire dynamique. Il faut bien chasser les risques de boucles, mais aussi de récursivités cachée et compter avec soin la profondeur d'héritage des objets.
En effet très vite on instancie un objet ,une de ses méthodes fait appel à un autre objet qui dans son constructeur ou ailleur instancie un new du premier objet et nous avons là une belle règle d'intanciation par héritage indirect qui est récursive.
Le mieux pour suivre ces risques c'est de tracer dans un fichier log les intances d'objets et leurs héritages respectifs.
Il suffit de placer un fichier en global et une écriture en début de constructeur et une écriture juste avant le new qui dis dans quelle partie du code il est appelé.
Tu pourra également compter le niveau de profondeur et le nombre d'instance en ajoutant les attributs ad hoc.
Bon courrage
retient aussi ce que t'ont dis les posts antérieurs les pistes de boucles infinies cachée par un ou deux niveaux d'appel ou un effet de bord :
variable globale manipulée dans deux fonctions différentes, string trop grande qui déborde de sa réservation et écrase une variable derrière ....
En C++ (comme dans beaucoup de langage quand on utilise de l'allocation dynamique de ressources) l'instanciation d'objet est une demande d'allocation de mémoire dynamique. Il faut bien chasser les risques de boucles, mais aussi de récursivités cachée et compter avec soin la profondeur d'héritage des objets.
En effet très vite on instancie un objet ,une de ses méthodes fait appel à un autre objet qui dans son constructeur ou ailleur instancie un new du premier objet et nous avons là une belle règle d'intanciation par héritage indirect qui est récursive.
Le mieux pour suivre ces risques c'est de tracer dans un fichier log les intances d'objets et leurs héritages respectifs.
Il suffit de placer un fichier en global et une écriture en début de constructeur et une écriture juste avant le new qui dis dans quelle partie du code il est appelé.
Tu pourra également compter le niveau de profondeur et le nombre d'instance en ajoutant les attributs ad hoc.
Bon courrage
retient aussi ce que t'ont dis les posts antérieurs les pistes de boucles infinies cachée par un ou deux niveaux d'appel ou un effet de bord :
variable globale manipulée dans deux fonctions différentes, string trop grande qui déborde de sa réservation et écrase une variable derrière ....
Char Snipeur
Messages postés
9696
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
2 oct. 2008 à 13:26
2 oct. 2008 à 13:26
Et aussi une erreur bien tordu :
https://cpp.developpez.com/faq/cpp/?page=Les-donnees-et-fonctions-membres-statiques#CONSTRUCTEUR_static_fiasco
https://cpp.developpez.com/faq/cpp/?page=Les-donnees-et-fonctions-membres-statiques#CONSTRUCTEUR_static_fiasco
jihelge
Messages postés
71
Date d'inscription
mardi 5 février 2008
Statut
Membre
Dernière intervention
4 octobre 2008
7
2 oct. 2008 à 13:38
2 oct. 2008 à 13:38
Oui Char Snipper
Bien vu
bien se rappeler qu'un "programme" en C++ est du code actif AVANT démarrage réel du main programme
puisque les méthodes constructeurs s'exécutent lors de la phase auto_init
attention aussi aux statique puisqu'on peut avoir de l'effet de bord
Bien vu
bien se rappeler qu'un "programme" en C++ est du code actif AVANT démarrage réel du main programme
puisque les méthodes constructeurs s'exécutent lors de la phase auto_init
attention aussi aux statique puisqu'on peut avoir de l'effet de bord
jihelge
Messages postés
71
Date d'inscription
mardi 5 février 2008
Statut
Membre
Dernière intervention
4 octobre 2008
7
3 oct. 2008 à 11:30
3 oct. 2008 à 11:30
Bonjour,
Que win plante tout seul ! A l'ouest rien de nouveau. J'ai fait un audit technique pour la DDE IDF en 1998 pour cela.
Mais j'ai également audité des codes en c++ (service des autoroutes) qui modélisaient le parcours de ces merveilleux rubans d'asphalte sous SUN OSX, nous avions plus de 30 niveaux d'héritage et la désallocation de ressources ce n'était pas ça. Il faut chasser les alloc jamais désalouées car toutes les ressources dynamiques (sémaphores, partitions mémoire,...) sont données par le système qui lui même se les bouffe pareil (surtout sous Win qui est hyper mal br..lé pour ça).
Pour le PC de ton père qui rame comme une galère : deux trucs à faire :
éteindre effectivement ça permettra la "dé-gruyèrisation" de la mémoire et du tampon de mémoire virtuelle.
nettoyer le disque et le défragmenter
Tu va voir quand il reprendra sa deux chevaux il aura l'impression d'avoir une ferrari.
A oui aussi, virer tout les grigris qui font coincoin dans tous les angles qui ne servent à rien et qui bouffe des ressources (comme Merlin et autres co..eries) il faut tout dépouiller.
Que win plante tout seul ! A l'ouest rien de nouveau. J'ai fait un audit technique pour la DDE IDF en 1998 pour cela.
Mais j'ai également audité des codes en c++ (service des autoroutes) qui modélisaient le parcours de ces merveilleux rubans d'asphalte sous SUN OSX, nous avions plus de 30 niveaux d'héritage et la désallocation de ressources ce n'était pas ça. Il faut chasser les alloc jamais désalouées car toutes les ressources dynamiques (sémaphores, partitions mémoire,...) sont données par le système qui lui même se les bouffe pareil (surtout sous Win qui est hyper mal br..lé pour ça).
Pour le PC de ton père qui rame comme une galère : deux trucs à faire :
éteindre effectivement ça permettra la "dé-gruyèrisation" de la mémoire et du tampon de mémoire virtuelle.
nettoyer le disque et le défragmenter
Tu va voir quand il reprendra sa deux chevaux il aura l'impression d'avoir une ferrari.
A oui aussi, virer tout les grigris qui font coincoin dans tous les angles qui ne servent à rien et qui bouffe des ressources (comme Merlin et autres co..eries) il faut tout dépouiller.
Utilisateur anonyme
3 oct. 2008 à 14:17
3 oct. 2008 à 14:17
Bonjour à tous,
Bon, voyant que mes observations ont été apprécié, j'en ajouterai quelques autres ...
Je ne suis pas expert du C++, j'ai codé en C sur quelques grosses application,
exemple le LiMCA ( Liquid Metal Cleanleness Analyser ) developpé en collaboration
avec l'ALCAN.
Et dans une autre job, J'ai écris des BIOS en C pour des outils de diagnostiques
sur des circuits imprimés sortant directement de la production.
Je suis d'accord avec ce qui a été dit quand au fait qu'il faut bien gérer la
désallocation de mémoire. Toutefois ce qui me donne le signe de se pencher sur l'OS,
c'est que tu dis que l'appli gèle et une fois stoppé, tu la repart et le tout fonctionne.
Lors du prochain plantage, vérifie d'abord les ressources systémes du poste pendant
le plantage // Clic droit sur barre des taches / Gestionnaire des tâches / Onglet Processus
Regarde bien dans le bas de la fenêtre les valeurs de UC utilisée ainsi que la Charge dédié.
Tu peux aussi avoir ces infos dans l'onglet performance. En pratique lorsque l'appli tourne
le processeur (UC) ne devrait jamais utilisé plus de 50% (moyenne).
Refait le même exercice une fois l'appli arrête et redémarrer.
Je m'explique : Pour tout système à micro processeur, il existe ce que nous appellons
des IRQs ( Interrupt Request ), ces IRQs sont vectorisées dans le BIOS dans les toutes
dernières adresses. Or lorsque qu'une IRQ est déclenché, le processeur doit empiler
dans la mémoire l'état de ce qu'il est en train d'exécuter, la valeurs des ses régistres
et des ses pointeurs. N'oublions pas que ton appli tourne avec un paquet d'autres
processus et/ou service qui utilisent aussi de la mémoire et dont les valeurs (pointeurs,
registre d'états, etc... doivent être empiler dans le stack qui est une plage mémoire réservé par l'UC.
Si ton système de fichier est fragmenté énormément, les ressources requises au moment
des IRQs sont décuplé. Si ton disque possède des secteurs défectueux non déclaré,
au moment d'écrire dans le swapfile ( partie mémoire vive et partie disque dur ), cela peut
entrainer ce genre de problème.
Je ne dis pas qu'il n'y a pas un problème d'optimisation de désallocation de mémoire dans
le programme en C++, lorsque je codé en C++, je place toujours des [ cout ] (instruction
d'affichage) dans mes constructeurs ainsi que dans mes destructeurs, ainsi je m'assure de
la désallocation de chaque objet instancié. Une fois les tests unitaires effectués, je retire ces
instruction [ cout ].
Notez que je suis sensible à la quincaillerie ainsi qu'au système de fichier ayant eu une formation
technique en électronique, mon premier emploi était de dessiner des cartes mère. Aujourd'hui
je suis administrateur et analyste d'un logiciel spécialisé qui désert près de 500 usagers.
s.v.p. soyez indulgent pour l'ortographe, je n'ai pas beaucoup de temps et ne revise pas souvent
le texte que j'écris.
En toute amitié :-)
Lupin
Bon, voyant que mes observations ont été apprécié, j'en ajouterai quelques autres ...
Je ne suis pas expert du C++, j'ai codé en C sur quelques grosses application,
exemple le LiMCA ( Liquid Metal Cleanleness Analyser ) developpé en collaboration
avec l'ALCAN.
Et dans une autre job, J'ai écris des BIOS en C pour des outils de diagnostiques
sur des circuits imprimés sortant directement de la production.
Je suis d'accord avec ce qui a été dit quand au fait qu'il faut bien gérer la
désallocation de mémoire. Toutefois ce qui me donne le signe de se pencher sur l'OS,
c'est que tu dis que l'appli gèle et une fois stoppé, tu la repart et le tout fonctionne.
Lors du prochain plantage, vérifie d'abord les ressources systémes du poste pendant
le plantage // Clic droit sur barre des taches / Gestionnaire des tâches / Onglet Processus
Regarde bien dans le bas de la fenêtre les valeurs de UC utilisée ainsi que la Charge dédié.
Tu peux aussi avoir ces infos dans l'onglet performance. En pratique lorsque l'appli tourne
le processeur (UC) ne devrait jamais utilisé plus de 50% (moyenne).
Refait le même exercice une fois l'appli arrête et redémarrer.
Je m'explique : Pour tout système à micro processeur, il existe ce que nous appellons
des IRQs ( Interrupt Request ), ces IRQs sont vectorisées dans le BIOS dans les toutes
dernières adresses. Or lorsque qu'une IRQ est déclenché, le processeur doit empiler
dans la mémoire l'état de ce qu'il est en train d'exécuter, la valeurs des ses régistres
et des ses pointeurs. N'oublions pas que ton appli tourne avec un paquet d'autres
processus et/ou service qui utilisent aussi de la mémoire et dont les valeurs (pointeurs,
registre d'états, etc... doivent être empiler dans le stack qui est une plage mémoire réservé par l'UC.
Si ton système de fichier est fragmenté énormément, les ressources requises au moment
des IRQs sont décuplé. Si ton disque possède des secteurs défectueux non déclaré,
au moment d'écrire dans le swapfile ( partie mémoire vive et partie disque dur ), cela peut
entrainer ce genre de problème.
Je ne dis pas qu'il n'y a pas un problème d'optimisation de désallocation de mémoire dans
le programme en C++, lorsque je codé en C++, je place toujours des [ cout ] (instruction
d'affichage) dans mes constructeurs ainsi que dans mes destructeurs, ainsi je m'assure de
la désallocation de chaque objet instancié. Une fois les tests unitaires effectués, je retire ces
instruction [ cout ].
Notez que je suis sensible à la quincaillerie ainsi qu'au système de fichier ayant eu une formation
technique en électronique, mon premier emploi était de dessiner des cartes mère. Aujourd'hui
je suis administrateur et analyste d'un logiciel spécialisé qui désert près de 500 usagers.
s.v.p. soyez indulgent pour l'ortographe, je n'ai pas beaucoup de temps et ne revise pas souvent
le texte que j'écris.
En toute amitié :-)
Lupin
little_titi
Messages postés
242
Date d'inscription
lundi 31 mars 2008
Statut
Membre
Dernière intervention
23 novembre 2009
7
6 oct. 2008 à 14:27
6 oct. 2008 à 14:27
Re bonjour à tous!!
bon alors voila où j'en suis : après une longue analyse de la situation, il semblerait que le problème puisse venir soit d'un mauvais transit d'information entre le périphérique, le soft et la machine (auquel cas, on va essayé de mettre en place un contrôle sur la gestion du port Série pour que 2 trames ne se retrouvent pas à transiter en même temps vers le lecteur de carte), soit un problème lié à notre "bon" vieux windows...car les machines ne sont jamais redémarrées (ils redémarrent seulement quand ça bug!!!)jamais de scandisk ou de défrag n'est effectué...et avant paraît-il qu'un redémarrage automatique de windows avait été programmé tous les matins vers 4h mais que depuis un très long moment ce démarrage auto aurait été enlevé!
ça commence je pense à se profiler...
je vous tiens au courant de la suite des événements merci à tous pour vos précieuses aides!
bon alors voila où j'en suis : après une longue analyse de la situation, il semblerait que le problème puisse venir soit d'un mauvais transit d'information entre le périphérique, le soft et la machine (auquel cas, on va essayé de mettre en place un contrôle sur la gestion du port Série pour que 2 trames ne se retrouvent pas à transiter en même temps vers le lecteur de carte), soit un problème lié à notre "bon" vieux windows...car les machines ne sont jamais redémarrées (ils redémarrent seulement quand ça bug!!!)jamais de scandisk ou de défrag n'est effectué...et avant paraît-il qu'un redémarrage automatique de windows avait été programmé tous les matins vers 4h mais que depuis un très long moment ce démarrage auto aurait été enlevé!
ça commence je pense à se profiler...
je vous tiens au courant de la suite des événements merci à tous pour vos précieuses aides!
jihelge
Messages postés
71
Date d'inscription
mardi 5 février 2008
Statut
Membre
Dernière intervention
4 octobre 2008
7
3 oct. 2008 à 15:46
3 oct. 2008 à 15:46
Héééé !
Il commence a y avoir de la matière pour écrire une thèse sur la prudence en écriture orientée objet
et sur les plantages de Windows
Bon aller
J'ai la tête comme un compteur à gaz, j'été faire un tour chez le dentiste qui m'a gardé une heure !!!!!!!
A bientôt tout le monde
Il commence a y avoir de la matière pour écrire une thèse sur la prudence en écriture orientée objet
et sur les plantages de Windows
Bon aller
J'ai la tête comme un compteur à gaz, j'été faire un tour chez le dentiste qui m'a gardé une heure !!!!!!!
A bientôt tout le monde
3 oct. 2008 à 09:40
Mais en tout cas, je suis bien content d'avoir l'exemple d'un pro ayant travail sur le sujet pour critiquer la stabilité de MS, chiffré etc.
Personnelement, je redémarre mes PC win tout les jours, et je suis très content de mon XP.
D'un autre coté, mon père laisse le sien allumé 24/24 7/7 et c'est un limace anémique.
Mais de là à en tirer une loi sur une courbe à deux points...
Le plus probable serai peut être alors que Win plante la lecture du périphérique et que le programme C++ soit alors à la ramasse. Il faudrait augmenter sa robustesse en mettant des controles dans la gestion du périphérique (timestamp etc.).
3 oct. 2008 à 11:02
je vais voir aussi comme il disait : "l'écriture dans un endroit non attendu : comme le "buffer overflow" tu dépasse la taille d'un tableau, mais tu écris dans une zone mémoire appartenant au programme modifiant une autre donnée." Peut-être que ça vient de la aussi.
merci pour vos infos, je continu mes recherches!!
3 oct. 2008 à 12:21
Pour l'histoire du buffer overflow, sous windows je crois que ça plante de la manière suivante :
Tu as une fenêtre qui s'ouvre "le programme s'est arrêté de façon inattendue. Voulez-vous soumettre votre problème à Windows. Envoyer. Annuler." (enfin un truc du genre).
Donc à voir quand même mais à mon avis ton problème ne vient pas de là.
Cordialement
3 oct. 2008 à 13:27
double *a=new double[10];// pour être sur d'avoir 10 case double successif.
double *t1=a,*t2=a+5;
logiquement tu as deux tableaux de 5 cases chacune, seulement, si tu fait :
t1[6]=0; tu va écrire dans t2[1], ce que tu n'as pas forcément prévue. Mais comme tu écris dans une portion de mémoire autoriser, windows ne dira rien !
Bien sur, là l'exemple est bidon, mais peut très bien se produire avec 2 new.
D'ailleurs il m'ai souvent arriver de déclarer un tableau de 3 caractères et de pouvoir en écrire 5 sans qu'une erreur se produise. En fait, il me semble (là je ne suis pas sur, c'est du terrain de "vague comprehension") que lorsqu'on fait un new l'OS alloue au programme une quantité de mémoire minimum qui n'est pas un octet, mais peut être 8.