Je cherche un moyen (macros, option spécifique à un compilateur, ...) de
générer un tableau statique de pointeurs vers les fonctions du programme.
Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le
programme plante et affiche dans quelle fonction il a planté.
Je vais essayer de chercher du coté des infos de debug.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
thierry escola
Manu wrote:
Salut,
Je cherche un moyen (macros, option spécifique à un compilateur, ...) de générer un tableau statique de pointeurs vers les fonctions du programme. Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le programme plante et affiche dans quelle fonction il a planté. Je vais essayer de chercher du coté des infos de debug.
Une autre idée ?
Merci.
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
Thierry -- http://members.fortunecity.fr/tagada/
Manu wrote:
Salut,
Je cherche un moyen (macros, option spécifique à un compilateur, ...) de
générer un tableau statique de pointeurs vers les fonctions du programme.
Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le
programme plante et affiche dans quelle fonction il a planté.
Je vais essayer de chercher du coté des infos de debug.
Une autre idée ?
Merci.
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le
programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
Je cherche un moyen (macros, option spécifique à un compilateur, ...) de générer un tableau statique de pointeurs vers les fonctions du programme. Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le programme plante et affiche dans quelle fonction il a planté. Je vais essayer de chercher du coté des infos de debug.
Une autre idée ?
Merci.
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
Thierry -- http://members.fortunecity.fr/tagada/
Manu
thierry escola wrote:
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage. Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une solution portable. C'est juste pour voir ce qu'il est possible de faire.
thierry escola wrote:
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le
programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage.
Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une
solution portable.
C'est juste pour voir ce qu'il est possible de faire.
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage. Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une solution portable. C'est juste pour voir ce qu'il est possible de faire.
thierry escola
Manu wrote:
thierry escola wrote:
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage. Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une solution portable. C'est juste pour voir ce qu'il est possible de faire.
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
Thierry -- http://members.fortunecity.fr/tagada/
Manu wrote:
thierry escola wrote:
salut,
sans debogueur externe, ça semble pas facile. dans le cas où le
programme "plante" tu n'auras plus la main pour afficher quoi que ce
soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage.
Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une
solution portable.
C'est juste pour voir ce qu'il est possible de faire.
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans
ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
sans debogueur externe, ça semble pas facile. dans le cas où le programme "plante" tu n'auras plus la main pour afficher quoi que ce soit.
De ce coté là, ça va. J'arrive à afficher l'adresse de plantage. Je suis sous Linux (donc compilateur GCC) et je ne cherche pas une solution portable. C'est juste pour voir ce qu'il est possible de faire.
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
Thierry -- http://members.fortunecity.fr/tagada/
Manu
thierry escola wrote:
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
Mon idée c'est d'essayer d'afficher les infos qui ont menées au plantage, car un utilisateur "normal" utilise rarement ou pas du tout la capacité du système à générer des dumps. De plus même si ça a planté, il est parfois difficile de reproduire le bug. Je vais essayer de m'orienter vers une lecture des infos de débugage par l'exécutable lui même. Avec l'option -g1 de GCC il est possible de ne garder que les infos permettant de faire un backtrace. On garde ainsi une taille raisonnable pour l'exécutable tout en gardant quelques infos utiles.
Mon idée est peut-être mauvaise ou infaisable, mais bon, c'est aussi pour le fun.
thierry escola wrote:
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans
ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
Mon idée c'est d'essayer d'afficher les infos qui ont menées au
plantage, car un utilisateur "normal" utilise rarement ou pas du tout la
capacité du système à générer des dumps. De plus même si ça a planté, il
est parfois difficile de reproduire le bug.
Je vais essayer de m'orienter vers une lecture des infos de débugage par
l'exécutable lui même.
Avec l'option -g1 de GCC il est possible de ne garder que les infos
permettant de faire un backtrace. On garde ainsi une taille raisonnable
pour l'exécutable tout en gardant quelques infos utiles.
Mon idée est peut-être mauvaise ou infaisable, mais bon, c'est aussi
pour le fun.
je n'ai pas encore utilisé gdb, mais si tu as les infos de compil dans ton exécutable, tu devrais avoir le source sous gdb pour "suivre"
Mon idée c'est d'essayer d'afficher les infos qui ont menées au plantage, car un utilisateur "normal" utilise rarement ou pas du tout la capacité du système à générer des dumps. De plus même si ça a planté, il est parfois difficile de reproduire le bug. Je vais essayer de m'orienter vers une lecture des infos de débugage par l'exécutable lui même. Avec l'option -g1 de GCC il est possible de ne garder que les infos permettant de faire un backtrace. On garde ainsi une taille raisonnable pour l'exécutable tout en gardant quelques infos utiles.
Mon idée est peut-être mauvaise ou infaisable, mais bon, c'est aussi pour le fun.
kilobug
Manu wrote:
Salut, Je cherche un moyen (macros, option spécifique à un compilateur, ...) de générer un tableau statique de pointeurs vers les fonctions du programme. Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le programme plante et affiche dans quelle fonction il a planté. Je vais essayer de chercher du coté des infos de debug. Une autre idée ? Merci.
On va encore me dire que je fais de la propagande GNU, mais la seule solution que je connaisse utilise la libc GNU (et n'est donc pas standard), via les fonctions backtrace, backtrace_symbols et backtrace_symbols_fd
Elles sont documentées dans info libc, et je les utilise dans le signal handler de SEGV ainsi que dans les mutex pour afficher le stacktrace du thread ayant le lock et du thread voulant le lock en cas de timeout (ce qui permet de débugguer les deadlocks bcp plus facilement)
Si quelqu'un connait une solution portable, je suis preneur :)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Manu wrote:
Salut,
Je cherche un moyen (macros, option spécifique à un compilateur,
...) de générer un tableau statique de pointeurs vers les fonctions
du programme.
Ca serait pour essayer faire une sorte d'autodebug dans un
programme. Le programme plante et affiche dans quelle fonction il a
planté.
Je vais essayer de chercher du coté des infos de debug.
Une autre idée ?
Merci.
On va encore me dire que je fais de la propagande GNU, mais la seule
solution que je connaisse utilise la libc GNU (et n'est donc pas
standard), via les fonctions backtrace, backtrace_symbols et
backtrace_symbols_fd
Elles sont documentées dans info libc, et je les utilise dans le
signal handler de SEGV ainsi que dans les mutex pour afficher le
stacktrace du thread ayant le lock et du thread voulant le lock en cas
de timeout (ce qui permet de débugguer les deadlocks bcp plus
facilement)
Si quelqu'un connait une solution portable, je suis preneur :)
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Salut, Je cherche un moyen (macros, option spécifique à un compilateur, ...) de générer un tableau statique de pointeurs vers les fonctions du programme. Ca serait pour essayer faire une sorte d'autodebug dans un programme. Le programme plante et affiche dans quelle fonction il a planté. Je vais essayer de chercher du coté des infos de debug. Une autre idée ? Merci.
On va encore me dire que je fais de la propagande GNU, mais la seule solution que je connaisse utilise la libc GNU (et n'est donc pas standard), via les fonctions backtrace, backtrace_symbols et backtrace_symbols_fd
Elles sont documentées dans info libc, et je les utilise dans le signal handler de SEGV ainsi que dans les mutex pour afficher le stacktrace du thread ayant le lock et du thread voulant le lock en cas de timeout (ce qui permet de débugguer les deadlocks bcp plus facilement)
Si quelqu'un connait une solution portable, je suis preneur :)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Manu
Gaël Le Mignot wrote:
On va encore me dire que je fais de la propagande GNU, mais la seule solution que je connaisse utilise la libc GNU (et n'est donc pas standard), via les fonctions backtrace, backtrace_symbols et backtrace_symbols_fd
C'est excellent...
Elles sont documentées dans info libc, et je les utilise dans le signal handler de SEGV ainsi que dans les mutex pour afficher le stacktrace du thread ayant le lock et du thread voulant le lock en cas de timeout (ce qui permet de débugguer les deadlocks bcp plus facilement)
... ou presque. Je passe également par le signal handler de SEGV pour afficher le stacktrace, mais je suis déçu car le stacktrace affiché n'est pas bon. Et je pense que cela vient du fait qu'il commence en partant du signal handler, ce aui doit fosser un peu le truc.
Mon exemple n'est pas compliqué (je ne l'ai pas sous la main) et se compose du signal handler et d'un main avec un sigaction et un printf qui doit provoqué le plantage, genre
printf("%dn", *((int*)NULL));
Mais je soupçonne que cela viennent du sigaction qui empile plein de trucs avant l'appel au handler. Je vais essayer avec un signal(SIGSEGV,...) tout con.
Mais merci beaucoup, c très pratique et bon à savoir. Et puis j'ai découvert la très bonne doc de la libc.
Gaël Le Mignot wrote:
On va encore me dire que je fais de la propagande GNU, mais la seule
solution que je connaisse utilise la libc GNU (et n'est donc pas
standard), via les fonctions backtrace, backtrace_symbols et
backtrace_symbols_fd
C'est excellent...
Elles sont documentées dans info libc, et je les utilise dans le
signal handler de SEGV ainsi que dans les mutex pour afficher le
stacktrace du thread ayant le lock et du thread voulant le lock en cas
de timeout (ce qui permet de débugguer les deadlocks bcp plus
facilement)
... ou presque. Je passe également par le signal handler de SEGV pour
afficher le stacktrace, mais je suis déçu car le stacktrace affiché
n'est pas bon. Et je pense que cela vient du fait qu'il commence en
partant du signal handler, ce aui doit fosser un peu le truc.
Mon exemple n'est pas compliqué (je ne l'ai pas sous la main) et se
compose du signal handler et d'un main avec un sigaction et un printf
qui doit provoqué le plantage, genre
printf("%dn", *((int*)NULL));
Mais je soupçonne que cela viennent du sigaction qui empile plein de
trucs avant l'appel au handler.
Je vais essayer avec un signal(SIGSEGV,...) tout con.
Mais merci beaucoup, c très pratique et bon à savoir. Et puis j'ai
découvert la très bonne doc de la libc.
On va encore me dire que je fais de la propagande GNU, mais la seule solution que je connaisse utilise la libc GNU (et n'est donc pas standard), via les fonctions backtrace, backtrace_symbols et backtrace_symbols_fd
C'est excellent...
Elles sont documentées dans info libc, et je les utilise dans le signal handler de SEGV ainsi que dans les mutex pour afficher le stacktrace du thread ayant le lock et du thread voulant le lock en cas de timeout (ce qui permet de débugguer les deadlocks bcp plus facilement)
... ou presque. Je passe également par le signal handler de SEGV pour afficher le stacktrace, mais je suis déçu car le stacktrace affiché n'est pas bon. Et je pense que cela vient du fait qu'il commence en partant du signal handler, ce aui doit fosser un peu le truc.
Mon exemple n'est pas compliqué (je ne l'ai pas sous la main) et se compose du signal handler et d'un main avec un sigaction et un printf qui doit provoqué le plantage, genre
printf("%dn", *((int*)NULL));
Mais je soupçonne que cela viennent du sigaction qui empile plein de trucs avant l'appel au handler. Je vais essayer avec un signal(SIGSEGV,...) tout con.
Mais merci beaucoup, c très pratique et bon à savoir. Et puis j'ai découvert la très bonne doc de la libc.
