Backtrack crash handler
Résolu/Fermé
scriptor
-
Modifié par scriptor le 18/10/2011 à 23:21
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 20 oct. 2011 à 10:28
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 20 oct. 2011 à 10:28
A voir également:
- Backtrack crash handler
- Office xml handler - Télécharger - Traitement de texte
- Backtrack linux - Télécharger - Sécurité
- Windows crash - Guide
- Pc crash - Guide
- Pdf preview handler ✓ - Forum Windows 10
1 réponse
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
19 oct. 2011 à 09:58
19 oct. 2011 à 09:58
C'est la pile d'appel (cf cours de langage C) qui était active au moment du plantage. À un instant donné, une fonction f peut appeler une fonction g qui va appeler une fonction h. Dans ce cas en pile tu verras h en haut de pile, en dessous g, et en dessous f.
La pile est stockée en mémoire. Chaque élément de la pile a donc une adresse mémoire en fonction de sa position en pile (c'est pour ça que les adresses se suivent).
La place occupée par une fonction en pile est plus ou moins importante selon le prototype de la fonction (plus exactement par rapport à la taille des paramètres qui lui sont passés et la taille de son type de retour).
Si la pile se remplit trop (comprendre si le programme est mal développé, typiquement un appel récursif invoqué des centaines de fois) la pile peut déborder (stack overflow).
Concrètement ces adresses ne sont pas super utiles pour toi. C'est surtout utile pour le debugger (pour remettre en forme la pile d'appel sous une forme plus lisible).
Pour un développeur cette interprétation plus lisible (QApplication::exec() qui appelle QEventLoop::exec() etc...) est utile pour savoir dans quel contexte ton programme a planté. En particulier l'appel le plus haut dans la pile lui permet de savoir à quelle ligne précisément le programme a planté (cf #1) et la raison de se plantage (que tu as masqué également), par exemple l'accès à une zone mémoire invalide (segmentation fault).
Ainsi, il est toujours utile lorsqu'une application plante de reporter la pile d'appel. Ne pas la fournir revient en quelque sorte à dire aux gens qui corrigent les bugs "ça plante" mais sans leur dire "où et pourquoi", donc sans cette trace, ils ne peuvent pas faire grand chose !
Ici c'est manifestement une application KDE, donc à reporter sur : https://bugs.kde.org/
D'un point de vue utilisateur, ce genre d'erreur n'est pas sensé se produire. Quand une telle erreur survient, c'est qu'il y a un bug (c'est pour ça que tu es sensé le remonter si quelqu'un ne l'a pas déjà fait, car tu n'es sans doute pas la seule personne confrontée au problème !). Il faut donc mettre à jour ton système (en espérant que ces mises à jours corrigent le bug).
Si tu as déjà la dernière version il peut arriver qu'on downgrade le paquet mis en cause quand le bug est paralysant, mais de manière générale on évite de downgrader.
La pile est stockée en mémoire. Chaque élément de la pile a donc une adresse mémoire en fonction de sa position en pile (c'est pour ça que les adresses se suivent).
La place occupée par une fonction en pile est plus ou moins importante selon le prototype de la fonction (plus exactement par rapport à la taille des paramètres qui lui sont passés et la taille de son type de retour).
Si la pile se remplit trop (comprendre si le programme est mal développé, typiquement un appel récursif invoqué des centaines de fois) la pile peut déborder (stack overflow).
Concrètement ces adresses ne sont pas super utiles pour toi. C'est surtout utile pour le debugger (pour remettre en forme la pile d'appel sous une forme plus lisible).
Pour un développeur cette interprétation plus lisible (QApplication::exec() qui appelle QEventLoop::exec() etc...) est utile pour savoir dans quel contexte ton programme a planté. En particulier l'appel le plus haut dans la pile lui permet de savoir à quelle ligne précisément le programme a planté (cf #1) et la raison de se plantage (que tu as masqué également), par exemple l'accès à une zone mémoire invalide (segmentation fault).
Ainsi, il est toujours utile lorsqu'une application plante de reporter la pile d'appel. Ne pas la fournir revient en quelque sorte à dire aux gens qui corrigent les bugs "ça plante" mais sans leur dire "où et pourquoi", donc sans cette trace, ils ne peuvent pas faire grand chose !
Ici c'est manifestement une application KDE, donc à reporter sur : https://bugs.kde.org/
D'un point de vue utilisateur, ce genre d'erreur n'est pas sensé se produire. Quand une telle erreur survient, c'est qu'il y a un bug (c'est pour ça que tu es sensé le remonter si quelqu'un ne l'a pas déjà fait, car tu n'es sans doute pas la seule personne confrontée au problème !). Il faut donc mettre à jour ton système (en espérant que ces mises à jours corrigent le bug).
Si tu as déjà la dernière version il peut arriver qu'on downgrade le paquet mis en cause quand le bug est paralysant, mais de manière générale on évite de downgrader.
Modifié par scriptor le 19/10/2011 à 23:11
pour le (cf #1) je n'ais rien caché les [...] c'était pour abrégé les lignes de (no debugging symbols found) j'ai tous mis, si j'ai ommis de le mettre ce n'était pas intentionnel.
mais en tous cas bien le merci ! ;)
20 oct. 2011 à 10:28
Bonne continuation !