Discussion :

[IPreferCSharp]

Bonjour,

J'ai une application dev en Python3.4 avec PyQt5. Cette application communique avec un appareil embarqué (envois et réception de trame).

J'ai une méthode (Exécutée depuis un QThread) qui récupère des événements stockés dans l'appareil ( Je peu en récupérer 5 comme 600, ça dépend).
Cette methode fonctionne bien en mode "release". Mais à un comportement bizarre quand je lance le mode debug depuis PyCharm. Si je n'ai pas de breakpoint, ça fonctionne, mais si je met un breakpoint ça crash au moment du breakpoint. Aucune exception n'est lancé (En tout cas je les attrapes pas) et le programme fini avec l'exit code 0.

J'ai un bouton recommencer pour lancer cette méthode. Si en mode release, je recommence encore et encore, au bout d'un certain moment, ça va crasher aussi avec le même comportement (exit code 0)

Le moment du crash et le nombre maximum de "recommencer" n'est pas tous le temps le même, ça a l'air de dépendre de la volumétrie de donnée à traiter. Si j'ai beaucoup de données, même en mode release, il peu ne pas terminer la fonction.

Ce comportement me fait penser à un probleme de mémoire mais je n'attrape aucune exception, j'ai regardé tous les try:except: , je re-raise toute les exceptions, j'ai aussi essayé d'ajouter ces lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
def on_exception_triggered(type_except, value, tb):
    import traceback
    trace = "".join(traceback.format_exception(type_except, value, tb))
    print("ERROR HOOKED : ", trace)
    sys.__excepthook__(type_except, value, tb)
 
sys.excepthook = on_exception_triggered

rien du tout. Avez vous une piste ?

[wiztricks]

Salut,

rien du tout. Avez vous une piste ?

Si votre code utilise des bibliothèques externes "wrappées" pour être utilisables par le programmeur Python, çà ne remontera que les erreurs "documentées". Pour les autres, le code C peut très bien faire un exit(0) sans remonter quoi que ce soit à l'interpréteur Python.
Pour le reste, c'est "business as usual": savoir reproduire rapidement le problème, ré-écrire le code pour délimiter quel composant est en cause, utiliser des outils systèmes pour tracer les allocations mémoire,...

- W