Chasser l'erreur de segmentation

Bonjour à tous !

J'ai écrit un programme de recherche de chemin (avec A* dedans), compilé avec gcc.
Je lance (dans un but statistique) la fonction une trentaine de fois dans le programme.
Dans la plupart des cas, une erreur de segmentation apparaît avant le trentième essai, mais comme elle peut se produire n'importe quand, si je cherche la ligne qui la cause en passant ligne après ligne dans GDB, je vais y passer des heures.
Y a-t-il un moyen (avec GDB ou autre) de savoir à quelle ligne se produit l'erreur ?

Normalement quand ça crashe GDB stoppe et t'indique la ligne courante. Après tu peux consulter la pile d'appels avec l'option backtrace, la valeur des variables, etc...

Si tu lances ton programme compilé en mode debug avec valgrind tu devrais avoir toutes les informations voulues au moment où ça segfaulte.

Merci pour vos réponses.

Je fais tourner mon programme à partir de gdb et obtiens la sortie
suivante (EK_Noeud est une de mes classes):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 (gdb) run Starting program: ~/TRAVAIL/2006-2007TIPE/PathFinder [Thread debugging using libthread_db enabled] [New Thread 805458416 (LWP 12492)] [...Sortie standard de mon programme...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805458416 (LWP 12492)] 0x10006204 in __gnu_cxx::new_allocator<EK_Noeud>::construct (this=0x7fda959f, __p=0x1003b370, __val=@0xf) at /usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:104 (gdb) Debugger finished
Comme ce programme utilise tout l'écran je ne peux ni voir le
débuggeur tourner (et comme il tourne dans emacs, cela me permettrait
de voir de code en même temps) ni contrôler le débuggeur.
Lors de l'arrêt du programme, il reste figé sur ce qu'il présentait à
l'écran au moment de mourir. Je suis obligé d'aller sur le tty1 pour
faire un $killall gdb (tuer mon programme ne fonctionne pas, il est
déjà mort, mais apparait quand je fais $ps -A) afin de
pouvoir récupérer la main.

La ligne correspondant à l'arrêt du programme est selon emacs, située
dans le fichier new_allocator.h, je l'ai
marquée d'un ==> :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 // Allocator that wraps operator new -*- C++ -*- [...] // This file is part of the GNU ISO C++ Library. This library is free [...] /** @file ext/new_allocator.h * This file is a GNU extension to the Standard C++ Library. */ #ifndef _NEW_ALLOCATOR_H #define _NEW_ALLOCATOR_H 1 #include <new> #include <bits/functexcept.h> namespace __gnu_cxx { /** * @brief An allocator that uses global new, as per [20.4]. * * This is precisely the allocator defined in the C++ Standard. * - all allocation calls operator new * - all deallocation calls operator delete */ [...] // _GLIbCXX_RESOLVE_LIB_DEFECT // 402. wrong new expression in [some_] allocator::construct void ==> construct(pointer __p, const _Tp& __val) { ::new(__p) _Tp(__val); } void destroy(pointer __p) { __p->~_Tp(); } }; [...] #endif
Cela ne m'avance pas beaucoup : comme je ne peux faire un backtrace,
je ne sais pas où est l'appel qui provoque la catastrophe.

Il est sans doute possible de faire tourner mon programme dans une
fenêtre, mais j'aimerais, avant de modifier le code en ce sens, savoir
s'il existe un moyen de voir le débuggeur et emacs plutot que mon
programme (qui utilise la DSL) lorsque celui-ci tourne.

J'ai modifié le programme, pour qu'il tourne dans une fenêtre (une constante à changer, c'est vraiment bien foutu, la SDL) et grâce à backtrace j'ai trouvé l'appel qui provoque le crash.

Merci beaucoup