Discussion :

[kimikou]

Bonsoir,

J'aimerai utiliser le fichier core lors de mes erreurs de segmentation mais les commandes que je fais ne générent pas de fichiers core.

Pourtant j'ai fais ulimit -c unlimited dans le terminal, puis gdb ./test core
et le terminal m'affiche alors :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/nom/dossier/src/test1/test...done.
/home/nom/dossier/src/test1/core: Aucun fichier ou dossier de ce type.

Code :

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

1
2
3
4
(gdb) run
Starting program: /home/nom/dossier/src/test1/test 
 
Program received signal SIGSEGV, Segmentation fault.

Que faut-il faire pour régler cela et donc utiliser le fichier core sans soucis ?

Merci d'avance

[Invité]

Bonjour,

Un "where" peut aider il donnera la pile des appels de fonctions/méthodes au moment du plantage et peut-être même les lignes de code où ont lieu les différents appels (dépend des options de compilation).

[kimikou]

D'accord merci mais j'aimerai quand même utiliser les fichiers core, si possible.

[Invité]

D'accord merci mais j'aimerai quand même utiliser les fichiers core, si possible.

Qu'entendez-vous par "utiliser le fichier core" ?
Quel est votre objectif ?

Un fichier core est l'image de la mémoire allouée par le programme au moment de son plantage.
On ne peut rien faire d'autre que d'observer la situation de la mémoire à ce moment (avec where, up ou print par exemple).
"run" exécute le programme, à ma connaissance, cette commande ignore le core chargé pour démarrer à nouveau le programme de zéro.

[D[r]eadLock]

Pour moi le process est le suivant:

$ gcc ... -g ... -o test
$ ulimit -c unlimited
$ ./test
Segmentation fault (core dumped)
$ gdb test core
> bt full

C'est l'exécution 'normale' (i.e. sans gdb) qui produit le core (grâce) à ulimit -c (il faut aussi voir /proc/sys/kernel/core_{pattern,uses_pid} pour voir le nom et format que vont prendre le fichier core.