j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?
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
Nicolas George
Kevin Denis , dans le message , a écrit :
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
Tu es sûr que le C est le plus adapté pour cet usage ? Quel volume de logs ? Quel genre de parsing ?
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
J'espère bien que le programme ne se termine pas avec un signal quand il rencontre une erreur de syntaxe, donc si, le code de retour t'aide, pour peu que tu l'utilises correctement, puisqu'il distingue bien un code de retour normal (de succès ou d'erreur mais normal) d'un signal.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Pour commencer, je pense que tu devrais lui faire produire un core. Tu peux vérifier si ça fonctionne bien en le faisant crasher exprès avec un SIGQUIT.
Il y a bien des solutions plus lourdes, strace et valgrind évidemment, mais je conseille de commencer par l'élémentaire.
Kevin Denis , dans le message
<slrnm7reje.6cn.kevin@slackwall.local.tux>, a écrit :
j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.
Tu es sûr que le C est le plus adapté pour cet usage ? Quel volume de logs ?
Quel genre de parsing ?
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.
J'espère bien que le programme ne se termine pas avec un signal quand il
rencontre une erreur de syntaxe, donc si, le code de retour t'aide, pour peu
que tu l'utilises correctement, puisqu'il distingue bien un code de retour
normal (de succès ou d'erreur mais normal) d'un signal.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?
Pour commencer, je pense que tu devrais lui faire produire un core. Tu peux
vérifier si ça fonctionne bien en le faisant crasher exprès avec un SIGQUIT.
Il y a bien des solutions plus lourdes, strace et valgrind évidemment, mais
je conseille de commencer par l'élémentaire.
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
Tu es sûr que le C est le plus adapté pour cet usage ? Quel volume de logs ? Quel genre de parsing ?
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
J'espère bien que le programme ne se termine pas avec un signal quand il rencontre une erreur de syntaxe, donc si, le code de retour t'aide, pour peu que tu l'utilises correctement, puisqu'il distingue bien un code de retour normal (de succès ou d'erreur mais normal) d'un signal.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Pour commencer, je pense que tu devrais lui faire produire un core. Tu peux vérifier si ça fonctionne bien en le faisant crasher exprès avec un SIGQUIT.
Il y a bien des solutions plus lourdes, strace et valgrind évidemment, mais je conseille de commencer par l'élémentaire.
JKB
Le 02 Dec 2014 09:30:19 GMT, Kevin Denis écrivait :
Bonjour,
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Bonsoir,
ulimit -u unlimited et un script de lancement devrait pouvoir détecter le segfault.
Sinon, si tu as les mains sur les sources, installe un gestionnaire de signaux sur SIGSEGV qui renvoie un code d'erreur spécifique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le 02 Dec 2014 09:30:19 GMT,
Kevin Denis <kevin@nowhere.invalid> écrivait :
Bonjour,
j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?
Bonsoir,
ulimit -u unlimited et un script de lancement devrait pouvoir
détecter le segfault.
Sinon, si tu as les mains sur les sources, installe un gestionnaire
de signaux sur SIGSEGV qui renvoie un code d'erreur spécifique.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le 02 Dec 2014 09:30:19 GMT, Kevin Denis écrivait :
Bonjour,
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Bonsoir,
ulimit -u unlimited et un script de lancement devrait pouvoir détecter le segfault.
Sinon, si tu as les mains sur les sources, installe un gestionnaire de signaux sur SIGSEGV qui renvoie un code d'erreur spécifique.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
MAIxxx
Le 02/12/2014 10:30, Kevin Denis a écrit :
Bonjour,
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Merci
Si tu peux compiler/linker facilement à partir du source le plus simple est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Au fur et à mesure tu peux ajouter/enlever des sorties de messages d'erreur sur un log. C'est *antique*, mais ça doit encore fonctionner. L'idée est d'avoir un cas de crash précis et de l'exploiter jusqu'à plus soif. Mais dans les applis, si le programmeur a de mauvaises habitudes, il peut rester plusieurs cas de crash différents, d'où l'idée d'en traiter un seul à la fois. cdt
Le 02/12/2014 10:30, Kevin Denis a écrit :
Bonjour,
j'aimerai surveiller un process. Ce process part un peu en quenouille de
temps à autre, et je voudrais savoir quand et pourquoi. C'est un
programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois
pas trop comment. Le code retour ne m'aide pas: le programme traite des
données, et il peut terminer avec un code d'erreur si les données sont
mal formattées: c'est un cas normal (et ça arrive assez souvent).
Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec
ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas
de crash. Une idée quelqu'un?
Merci
Si tu peux compiler/linker facilement à partir du source le plus simple
est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec
des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut
détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Au fur et à mesure tu peux ajouter/enlever des sorties de messages
d'erreur sur un log. C'est *antique*, mais ça doit encore fonctionner.
L'idée est d'avoir un cas de crash précis et de l'exploiter jusqu'à plus
soif. Mais dans les applis, si le programmeur a de mauvaises habitudes,
il peut rester plusieurs cas de crash différents, d'où l'idée d'en
traiter un seul à la fois.
cdt
j'aimerai surveiller un process. Ce process part un peu en quenouille de temps à autre, et je voudrais savoir quand et pourquoi. C'est un programme en C qui parse des logs.
En fait je voudrais surtout savoir s'il a segfaulté. Et là, je ne vois pas trop comment. Le code retour ne m'aide pas: le programme traite des données, et il peut terminer avec un code d'erreur si les données sont mal formattées: c'est un cas normal (et ça arrive assez souvent). Je veux le cas ou le programme crashe.
Je n'ai pas de soucis de perfs, je peux donc enrober le programme avec ce que je souhaite, mais j'ai vraiment besoin de connaitre les cas de crash. Une idée quelqu'un?
Merci
Si tu peux compiler/linker facilement à partir du source le plus simple est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Au fur et à mesure tu peux ajouter/enlever des sorties de messages d'erreur sur un log. C'est *antique*, mais ça doit encore fonctionner. L'idée est d'avoir un cas de crash précis et de l'exploiter jusqu'à plus soif. Mais dans les applis, si le programmeur a de mauvaises habitudes, il peut rester plusieurs cas de crash différents, d'où l'idée d'en traiter un seul à la fois. cdt
Dominique MICOLLET
Bonjourn
MAIxxx wrote:
Si tu peux compiler/linker facilement à partir du source le plus simple > est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Dans l'hypothèse ou l'auteur original de cet article possède les sources, je suggèrerais plutôt une compilation avec ajout des informations de débogage (option -g pour gcc ou g++) et l'usage d'un débogueur (j'aime bien ddd qui est une surcouche graphique de gdb).
Je crois que c'est aussi possible sur un code pour lequel on ne possède pas la source, voire sur le "core" qu'il génère lors de son plantage. Mais là, ça sort de ma compétence.
Cordialement
Dominique
Bonjourn
MAIxxx wrote:
Si tu peux compiler/linker facilement à partir du source le plus simple
> est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec
des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut
détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Dans l'hypothèse ou l'auteur original de cet article possède les sources, je
suggèrerais plutôt une compilation avec ajout des informations de débogage
(option -g pour gcc ou g++) et l'usage d'un débogueur (j'aime bien ddd qui
est une surcouche graphique de gdb).
Je crois que c'est aussi possible sur un code pour lequel on ne possède pas
la source, voire sur le "core" qu'il génère lors de son plantage. Mais là,
ça sort de ma compétence.
Si tu peux compiler/linker facilement à partir du source le plus simple > est de mettre des "prinf" ou "printerr" aux endroits stratégiques avec des paramètres ad hoc pour chaque point. C'est comme ça qu'on peut détecter l'endroit "où ça plante" quand on n'a pas d'idée.
Dans l'hypothèse ou l'auteur original de cet article possède les sources, je suggèrerais plutôt une compilation avec ajout des informations de débogage (option -g pour gcc ou g++) et l'usage d'un débogueur (j'aime bien ddd qui est une surcouche graphique de gdb).
Je crois que c'est aussi possible sur un code pour lequel on ne possède pas la source, voire sur le "core" qu'il génère lors de son plantage. Mais là, ça sort de ma compétence.
Cordialement
Dominique
Kevin Denis
Le 03-12-2014, Dominique MICOLLET a écrit :
Dans l'hypothèse ou l'auteur original de cet article possède les sources, je
En fait, non. C'est du vieux code "legacy".
J'ai testé un enrobage avec python. Grosso modo, ça ressemble à ça: def go(shell_command): debug_print("[.] Launching ... "+shell_command) proc = Popen(shell_command, shell=True, stdout=PIPE, stderr=PIPE) if proc.returncode == 139 or proc.returncode == -11: crash(shell_command)
Ca semble bon pour attraper l'erreur. -- Kevin
Le 03-12-2014, Dominique MICOLLET <anonymous@invalid.fr> a écrit :
Dans l'hypothèse ou l'auteur original de cet article possède les sources, je
En fait, non. C'est du vieux code "legacy".
J'ai testé un enrobage avec python. Grosso modo, ça ressemble à ça:
def go(shell_command):
debug_print("[.] Launching ... "+shell_command)
proc = Popen(shell_command, shell=True, stdout=PIPE, stderr=PIPE)
if proc.returncode == 139 or proc.returncode == -11:
crash(shell_command)