Re: Segmentation fault : Comment chercher?

Top Page

Reply to this message
Author: Francois-Xavier Kowalski
Date:  
To: anne aublanc
CC: guilde
Subject: Re: Segmentation fault : Comment chercher?
>
>
>| > Comment faire pour voir une trace de log quelque part... C'est un pgm
>| > binaire....
>|
>| fais
>|
>|     ulimit -c unlimited
>|
>| dans ton shell avant de lancer le programme (compilé avec -g). Avec ça
>| le message d'erreur devrait devenir
>|
>|     Segmentation fault (core dumped)
>|
>[root@maison1 root]# ulimit -c unlimited

>


Essaie:

ulimit -S -c unlimited

pour verifier que c'est Ok, un petit "programme" core.c

main()
{
        *(char*)0 = 1;
}


gcc core.c
./a.out
Segmentation fault (core dumped)

>[root@maison1 root]# faxgetty ttyS0
>Segmentation fault
>


Tu auras "(core-dumped)" en plus de "segmentation fault.

Si ce n'est pas le cas, regarde le contenu de /var/log/messages (a la
fin). Si tu trouve la chaine "Oops", tu viens te tomber sur ton premier
bug noyau ... :-)

>marche pas. pas de fichier core.
>
>| et tu trouveras un fichier core dans le répertoire courant que tu
>| pourras analyser au débogueur.
>|
>| Si tu ne sais pas te servir d'un débogueur, fais
>|
>|     gdb ton_programme core
>|
>| et dans gdb tape la commande "bt". Copie tout ce que gdb te répond, et
>| envoie ça par mail aux développeurs du programme, avec une note
>| expliquant le problème de façon détaillée. Tu peux leur envoyer aussi la
>| sortie de la commande "ldd ton_programme".
>|

>
>C'est pas gagné...
>Je n'arrive pas à trouver où mettre l'option de debug!!! ;o((
>
>C'est une grosse appli. Le configure fait 20 pages qui crée plusieurs
>makefile...
>J'ai trouvé 2 fichiers qui s'appelle defs et defs.in. Je pense que ce sont
>eux qui configurent la compil
>
>J'ai l'impression qu'il y a déjà l'option -g.
>


A toi de le dire: Il te suffit de regarder les commandes de compilation
lancees par le Makefile. Si "-g" ou "-ggdb" est qq part dans ces lignes,
c'est Ok. Il ne te reste plus qu'a parametrer ton systeme pour qu'il
autorise les core.

>j'ai récupéré 2 ou 3 lignes du fichier defs
>


A voir ce qui suit, tu peux peut-etre inclure le debug en utilisant la
commande:

make OPTIMIZER="-g"

>OPTIMIZER = -O
>
>GCOPTS = -g ${OPTIMIZER}
>
>GC++OPTS = -g ${OPTIMIZER}
>
>
>Dans le makefile :
>FAXGETTYOBJS= Getty.o GettySysV.o faxGettyApp.o
>
>faxgetty: ${FAXGETTYOBJS} libfaxserver.${DSO} ${LIBS}
>
>${C++F} -o $@ ${FAXGETTYOBJS} ${LIBFAXSERVER} ${LDFLAGS}
>
>
>Mon souci :
>aie, pas tapé! Je n'y connais rien....
>Je compile sur un disque et je teste sur un autre disque qui n'a pas les
>options de compil.
>J'ai installé gdb sur le dd de test..
>Je fais ce que tu as dit plus haut.
>Je me suis trompée quelque part?
>
>le résultat
>
>[root@maison1 root]# gdb faxgetty core
>GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
>Copyright 2001 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you are
>welcome to change it and/or distribute copies of it under certain
>conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB. Type "show warranty" for details.
>This GDB was configured as "i386-redhat-linux"...
>/root/core: No such file or directory.
>


Pas la peine de lancer gdb sur un fichier "core" si le fichier n'existe pas.

>(gdb) run
>Starting program: /usr/sbin/faxgetty
>
>Program exited with code 0377.
>(gdb) run bt
>


Pas bon : "bt" est une commande de gdb, au meme titre que "run".

>Starting program: /usr/sbin/faxgetty bt
>
>Program received signal SIGSEGV, Segmentation fault.
>0x42082a05 in memcpy () from /lib/i686/libc.so.6
>(gdb) quit
>


La tu fait "bt" (qui signifie "backtrace", ou encore "pile d'appel") au
lieu de "quit".

>The program is running. Exit anyway? (y or n) y
>[root@maison1 root]#
>
>

--
Francois-Xavier 'FiX' KOWALSKI