Débogage de la mémoire Python avec GDB

Question

Nous avons une application Linux qui utilise les liaisons Python d’OpenSSL et je suppose que cela provoque des plantages aléatoires. De temps en temps, on le voit planter avec le message:

  

Erreur irrécupérable Python: un objet GC a déjà fait l'objet d'un suivi

qui semble être soit une erreur de programmation de la part de la bibliothèque, soit un symptôme de corruption de la mémoire. Existe-t-il un moyen de connaître la dernière ligne du code source Python qu'il a exécuté, à partir d'un fichier core? Ou si elle est attachée dans GDB? Je me rends compte que ce sont probablement tous des codes bytile compilés, mais j'espère que quelqu'un pourra avoir traité ce problème. Actuellement, il fonctionne avec le module de trace actif et nous espérons que cela se reproduira, mais cela pourrait être long.

Answer 1

Oui, vous pouvez faire ce genre de chose:

(gdb) print PyRun_SimpleString("import traceback; traceback.print_stack()")
  File "<string>", line 1, in <module>
  File "/var/tmp/foo.py", line 2, in <module>
    i**2
  File "<string>", line 1, in <module>
$1 = 0

Il devrait également être possible d'utiliser la commande pystack définie dans le python gdbinit , mais cela ne fonctionne pas pour moi. Nous en avons discuté ici si vous souhaitez examiner la question.

De même, si vous soupçonnez des problèmes de mémoire, vous pouvez utiliser valgrind . avec python, si vous êtes prêt à le recompiler. La procédure est décrite ici.

Answer 2

Si vous avez des problèmes avec Mac ou Sun Box, vous pouvez utiliser dtrace et une version de Python compilé avec dtrace pour comprendre ce que l’application faisait à l’époque. Remarque: en 10.5 python est pré-compilé avec dtrace, ce qui est vraiment agréable et pratique.

Si cela ne vous est pas disponible, vous pouvez alors importez gc et activez le débogage que vous pouvez ensuite transférer dans un fichier journal.

Pour répondre spécifiquement à votre question concernant le débogage avec GDB, vous pouvez lire " Débogage avec GDB " sur le wiki python.

Answer 3

Si vous utilisez CDLL pour emballer une bibliothèque C en python, et que vous utilisez un Linux 64 bits, il y a de bonnes chances que votre enveloppe CDLL soit mal configurée. CDLL utilise par défaut les types de renvoi int sur toutes les plates-formes (cela devrait être long sur les systèmes 64 bits) et s'attend à ce que vous passiez les bons arguments. Vous devrez peut-être vérifier le wrapper CDLL dans ce cas ...

Answer 4

En plus de tout ce qui précède, vous pouvez rapidement implémenter un traceur adhoc via le module de trace .