Assert.h et état de la pile [resolu] - comment en connaitre l'état

Voilà, j’ai un programme avec des asserts partout.
Seulement j’en ai un qui stoppe l’exécution, mais dans quelle fonction a-t-il été appelé? j’arrive pas à le savoir. J’ai bien essayé par gdb, mais il intervient tard (vraiment très tard) dans l’exécution.
Je me demandais si plus simlement, il n’y aurait pas moyen de stocker l’état du programme quand il sort, histoire de s’en servir, un peu à l’image de ce que fait gprof?

je me réponds, ce sont les fichiers core, reste juste à trouver comment les générer. :slight_smile:

Bon, je crois avoir trouvé, un petit
ulimit -c unlimited
on lance le prog, le fichier core est créé
puis ensuite, on s’en occupe dans gdb.
C’est expliqué là comment faire:
http://www.freebsd.org/doc/fr/books/develo…/debugging.html
section: 5.6.3

Désolé! :ane:

euh pkoi tu dis pas tout simplement à gdb de s’arréter à la ligne juste avant ton assert ?

parce que le programme s’arrete dans une routine qui verifie les données avant de les utiliser, mais ce n’est pas cette routine qui pose probleme, c’est celle qui lui envoie les données “non valides”. Et le problème vient du fait que cette routine qui au début vérifie les données est appelée environ quelques dizaines de milliers de fois voire plus selon gprof… d’où ma difficulté à mettre un breakpoint dedans. Je sais pas si j’ai été clair. :miam:

Effectivement :stuck_out_tongue: vive le profilage en somme :jap:

Je debugge encore souvent à coup de cout ou de printf dans ce genre de cas.
Le tout est d’arriver à faire afficher juste ce qu’il faut pour que ce soit lissible (genre une valeur tous les N tours de boucles).

aussi horrible que ça paraisse je fais aussi de meme (perso, je me limite au printf), mais là, j’ai eu du mal à trouver où était la source du bug donc comment savoir où mettre des printf dans ce cas. Par ailleurs, si c’est pour en mettre 450 dans 650 fonctions, c’est pas top et au bout d’un moment c’est lourd! :o :paf: 'fin là c’est débuggé. No pb! :smiley: