Erreur de segmentation et redemarrage d'asterisk

[fab56]

Bonjour,

Je suis nouveau sur Asterisk (v1.4.44) et j'ai un problème que je n'arrive pas à résoudre.
Lorsque je passe un appel, asterisk s’arrête sur une erreur de segmentation alors qu'il y a 2 jours tout fonctionnait bien.
Voici une partie de mes logs :

-- Executing [21623710723@from-internal:1] SetAMAFlags("SIP/9621-00000000", "billing") in new stack
-- Executing [21623710723@from-internal:2] Set("SIP/9621-00000000", "CDR(accountcode)=9621") in new stack
-- Executing [21623710723@from-internal:3] Goto("SIP/9621-00000000", "outbound-allroutes||1") in new stack
-- Goto (outbound-allroutes,2161234587,1)
-- Executing [21623710723@outbound-allroutes:1] NoOp("SIP/9621-00000000", "Caller ID is 9621") in new stack
-- Executing [21623710723@outbound-allroutes:2] GotoIf("SIP/9621-00000000", "0?authorized") in new stack
-- Executing [21623710723@outbound-allroutes:3] mod_radauth("SIP/9621-00000000", "9621|9621|2161234587|BILLING|1400660978.0") in new stack
/usr/sbin/safe_asterisk: line 145: 18959 Segmentation fault (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.


Cela s’arrête donc la sur une erreur de segmentation. Je précise que mod_radauth est un module que nous avons développé pour notre besoin mais qui fonctionnait bien, donc je ne pense pas que cela viennent de ça.

Je ne sais plus trop ce que j'ai fait ces derniers jours pour que cela ne fonctionne plus mais je ne pense pas avoir touché à la configuration mise en place.
Est ce que la séquence SIP/9621-00000000 ou il n'y a que des zéros peut poser problème, alors que quand les appels passaient elle n’était pas à 0000000.

Pouvez-vous m'éclairer sur ce problème?

Merci d'avance.

[therebel23]

Et si tu désactives ce module mod_radauth temporairement, as-tu toujours l'erreur ?

[quintana]

gdb est ton ami :)

[fab56]

En désactivant le module, il n'y a plus l'erreur mais l'appel échoue. De toute façon ce module est obligatoire pour nous pour l'intégration avec un billing. Je ne comprends pas ce qui c'est passé puisque tout fonctionnait avant.

j'ai utilisé l'outil gdb mais cela ne m'avance pas plus. voici la trace:

(gdb) bt full
#0 find_option (rh=0x0, optname=0x2afe9577d96e "acctserver", type=4) at config.c:31
i = 0
#1 0x00002afe9577986e in rc_conf_srv (rh=0x0, optname=0x2afe9577d96e "acctserver") at config.c:506
option = <value optimized out>
#2 0x00002afe9577539e in ?? () from /usr/lib/asterisk/modules/app_mod_radauth.so
No symbol table info available.
#3 0x00002afe95776b15 in fetch_calldata () from /usr/lib/asterisk/modules/app_mod_radauth.so
No symbol table info available.
#4 0x00002afe95774dd1 in rc_ip_hostname () at ip_util.c:210
No symbol table info available.
#5 0x00000000004835ae in pbx_extension_helper ()
No symbol table info available.
#6 0x0000000000485a68 in __ast_pbx_run ()
No symbol table info available.
#7 0x0000000000486839 in pbx_thread ()
No symbol table info available.
#8 0x00000000004b2bbc in dummy_start ()
No symbol table info available.
#9 0x000000334b60683d in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x000000334aed4f8d in clone () from /lib64/libc.so.6
No symbol table info available.

[quintana]

Faut que tu compiles sans les optimisations faites par gcc sinon cela sera complexe avec gdb. Pourquoi les personnes qui ont développé ce module ne corrige pas l'erreur ? Tu as sois une race condition, soit un buffer overflow ou autre chose du genre. C'est pas parce que cela marchait il y a deux semaines que cela va marcher tout le temps ! Cela peut être pleins de choses ! Y a pas de magie en développement :)

[alfie01]

Bonjour,

Y a-t-il une raison spécifique pour utiliser la version 1.4?
Si tu compiles manuellement, pourquoi ne pas utiliser la dernière version LTS (Asterisk 11) ?
Meme Debian est passée à la version 1.8 dans Wheezy, c'est dire que la 1.4 est vieille...

Cdt,
Alfie
.

[fab56]

Les personnes qui ont développé ce module ne sont plus dans l'entreprise et moi au niveau du C, je suis pas un grand expert..
Sinon ce que tu me proposes c'est de recompiler juste mon module ou asterisk?

Merci de ton aide.

[fab56]

Bonjour,

Y a-t-il une raison spécifique pour utiliser la version 1.4?
Si tu compiles manuellement, pourquoi ne pas utiliser la dernière version LTS (Asterisk 11) ?
Meme Debian est passée à la version 1.8 dans Wheezy, c'est dire que la 1.4 est vieille...

Cdt,
Alfie
.

Non je ne crois pas qu'il y ait des raisons spécifiques pour utiliser cette version à part peut etre que notre module fonctionne sur la version 1.4et peut etre pas sur la 1.8.

Comme je l'ai deja dit, je suis tout nouveau sur asterisk et je découvre son fonctionnement.
Juste une petite question basique: le fait de recompiler Asterisk a-t-il un impact sur ls configurations deja en place (trunks, ...) ?

[quintana]

L'API Asterisk a changé entre 1.4 et 1.8 et pire 11 ! Dans ce cas-ci trouves une boite pour t'aider.

[alfie01]

Les personnes qui ont développé ce module ne sont plus dans l'entreprise et moi au niveau du C, je suis pas un grand expert..
Sinon ce que tu me proposes c'est de recompiler juste mon module ou asterisk?

Merci de ton aide.

Recompiler ton module ne servira pas a grand chose si le code n'a pas été modifié et s'il l'a été, il faut que tu analyses d'abord ce qui a été modifié et pourquoi.

Il semble y a un bug dans la fonction find_option de ton module qui fait tout planter parce qu'une conf a changé selon toute vraisemblance:

#0 find_option (rh=0x0, optname=0x2afe9577d96e "acctserver", type=4) at config.c:31

Si tu as des sauvegardes, essaye de retrouver une ancienne conf qui fonctionne et compares ce qui a changé. C'est vrai que si c'est une version de prod, vaut mieux pas upgrader à la légère, sans avoir bien tout testé avant...

Autrement si tu es vraiment bloqué et que tu as toutes les sources, envoie moi un MP avec tes coordonnées, je m'y connais un peu en debug asterisk, on pourra se faire une session screen pour voir ce qui fait planter cette fonction find_option...

Cdt,
Alfie
.

[fab56]

Recompiler ton module ne servira pas a grand chose si le code n'a pas été modifié et s'il l'a été, il faut que tu analyses d'abord ce qui a été modifié et pourquoi.

Il semble y a un bug dans la fonction find_option de ton module qui fait tout planter parce qu'une conf a changé selon toute vraisemblance:

#0 find_option (rh=0x0, optname=0x2afe9577d96e "acctserver", type=4) at config.c:31

Si tu as des sauvegardes, essaye de retrouver une ancienne conf qui fonctionne et compares ce qui a changé. C'est vrai que si c'est une version de prod, vaut mieux pas upgrader à la légère, sans avoir bien tout testé avant...

Cdt,
Alfie
.

Je te remercie beaucoup. J'avais pas pu regarder depuis.

J'ai vérifier mes confs ce matin et en 2 min j'ai trouvé un caractere "1" dans un fichier, que j'ai du taper sans faire exprès et quasi "invisible". Et pourtant ce fichier je les regardé plusieurs fois.:)

En tout cas mon problème est résolu et je vous remercie tous de votre aide.

[alfie01]

Je te remercie beaucoup. J'avais pas pu regarder depuis.

J'ai vérifier mes confs ce matin et en 2 min j'ai trouvé un caractere "1" dans un fichier, que j'ai du taper sans faire exprès et quasi "invisible". Et pourtant ce fichier je les regardé plusieurs fois.:)

En tout cas mon problème est résolu et je vous remercie tous de votre aide.

Content de savoir que tu as pu resoudre ton probleme!
Cela dit, c'est quand meme pas normal d'avoir un coredump juste a cause d'une erreur de conf...

Si tu cherches un coup de main pour mettre à jour ton asterisk et ce module, envoie-moi un MP.

Cdt,
A.