Mon application s'est écrasée récemment sur l'ordinateur d'un client. Je soupçonne que c'est à cause de la propre gestion de la mémoire de Pyqt, qui peut conduire à un accès à mémoire non valide lorsqu'il n'est pas correctement manipulé.
Lorsque Python s'écrase comme ceci, aucune backtrage n'est imprimée, seule une vidée de données est écrite sur le disque.
Il y a une possibilité de savoir où dans le code Python le crash a eu lieu?
Voici le vidage: http://pastie.org/768550
4 Réponses :
Est-ce un vidage de noyau Linux? Si oui, vous pouvez l'examiner avec GDB. Vous devrez exécuter sur un système avec un système d'exploitation et une version identiques de Python, y compris des bibliothèques tierces. Exécutez Quelle utilité cela dépend de la question de savoir si la version de Python inclut la table de symboles complète (c'est-à-dire une construction de débogage de Python) - si ce n'est pas le cas, vous ne verrez que des adresses que des décalages sur les points d'entrée principaux. Cependant, cela peut toujours être utilisé dans le diagnostic de ce qui s'est mal passé.
S'il s'agit d'un autre système d'exploitation qui ne prend pas en charge GDB, vous êtes seul - vraisemblablement, le système d'exploitation aura ses propres outils de débogage.
Il y a une page sur le wiki Python décrivant Comment obtenir une trace de pile Python avec gdb .
Cependant, un aspect rapide sur le lien de la question montre que le système d'exploitation est Windows, de sorte que GDB n'est pas utile. Les informations du décharge de Windows sont minimes, alors je pense que vous n'avez pas de chance.
Mes seules suggestions sont:
Essayez de reproduire l'accident en interne.
Obtenez l'utilisateur de reproduire le bogue lors de l'exécution d'un outil qui attrapera le crash et de faire un vidage de mémoire approprié. Il est environ une décennie depuis que j'ai fait de sérieux débogage de Windows, donc je ne sais pas quels outils sont disponibles maintenant - il y en avait un appelé Dr.Watson, mais cela peut être obsolète.
Si l'utilisateur ne peut pas reproduire l'accident, vous n'avez pas de chance, d'autre part si cela n'arrive jamais, ce n'est pas vraiment un gros problème. ; -)
Google me dit que le Dr Watson est toujours le gestionnaire de crash par défaut sur Windows XP (et d'autres versions de Windows) - le dépotoir de pile qui était lié à la question en résulte probablement. Cependant, les données par défaut enregistrées par le Dr Watson sont assez minimes, mais vous pouvez la configurer pour enregistrer plus - voir gdb -c / chemin / à / cœurs / fichier . Une fois que GDB a chargé, la commande bt répertoriera la trace de la pile pour le thread principal et le thread appliquer tout BT répertoriera la trace de la pile pour tous les threads.
drwtsn32 -i il apparaîtra une boîte de dialogue pour vous permettre de définir les options.
Nope, pas Linux à coup sûr (regardez la liste de processus dans le décharge: p)
Je serais vraiment intéressé par un Python Backtrace, que je ne peux pas utiliser avec GDB, je pense. (Symboliser le décharge devrait être possible, je pense.)
J'ai déjà essayé de le reproduire sur la machine de l'utilisateur, n'a pas fonctionné. Je veux dire qu'il y a une modification de 0,0000001% que la mémoire de l'utilisateur est corrompue ou que Windows vissait.
Je ne sais rien de Dr.Watson, mais de la liste des processus, on dirait que cela aurait pu être en cours d'exécution?
L'ordinateur est configuré pour stocker le vidage de données minimal (64 Ko), je suppose que je ne devrais pas gâcher ces paramètres. De plus, je ne pense pas que j'ai une grande chance d'obtenir quelque chose d'utile de cette pile minimale. Je suppose que je vais juste attendre que cela se reproduisait, puis essayez de le reproduire.
Votre application produit-elle un journal? Si tel est le cas, vous pouvez avoir une journalisation produira un journal en mémoire que vous pourrez peut-être trouver dans le dépotoir de base. En outre, vous pouvez leur avoir pour vous envoyer le fichier journal lui-même au lieu de la page du dépujet principal.
Il y a un fichier nommé Bien sûr, si le crash est si sévère qu'il a corrompu les structures internes de l'interprète, les macros peuvent échouer ou crash. En outre, il est préférable de compiler l'interprète en mode débogage, sinon GDB peut ne pas rechercher les symboles et les variables requis. gdbinit dans l'arborescence de source Python (dans misc / gdbinit ) qui fournit un ensemble de macros pour GDB afin d'afficher le contexte d'interpréteur actuel. Il suffit de taper source gdbinit dans gdb, puis vous pouvez exécuter des macros telles que pystack . La liste des macros disponibles peut être obtenue simplement en lisant le code source du fichier.
(Vous pouvez le trouver directement ici: http: // svn. python.org/view/python/trunk/misc/gdbinit?view=log ).
Vous ne savez pas si cela aide, mais si vous pouvez attraper l'exception, vous pouvez utiliser http://github.com / Gooli / Pydump Pour stocker une vidange et le charger plus tard dans un débogueur Python.