[AsteriskBrasil] Segfault no Asterisk com UniCall do Disc-OS

[Leonardo Gomes Figueira]

Pessoal do Disc-OS e usuários do chan_unicall em geral,

já uso o chan_unicall a um bom tempo e sempre tive problemas de
travamento e segfault do Asterisk com este mas devido a falta de opção
(atualmente existem outras opções de placas com R2, antigamente não)
sempre que o E1 tinha de ser MFC/R2 usei o chan_unicall (sempre que
posso escolho ISDN/PRI).

A alguns dias comecei a testar as versões disponibilizadas pela disto
Disc-OS que contêm algumas modificações na libmfcr2, libunicall e
chan_unicall.

Obtive os fontes de:

http://disc-os.svn.sourceforge.net/viewvc/disc-os/disc-os/trunk/chan_unicall/
http://disc-os.svn.sourceforge.net/viewvc/disc-os/disc-os/trunk/srpms/

Testei em um Asterisk 1.2.25 com Fedora 5 e não na distro Disc-OS
propriamente pois já tenho o servidor instalado.

Montei um ambiente de teste de carga gerando até 30 chamadas de duração
aleatória entre 2 E1s conectados entre si no mesmo servidor.

O resultado após horas de testes e milhares de chamadas geradas é o
mesmo que sempre obtive com a versão do UniCall que eu já usava: o
Asterisk trava (deadlock) ou quebra (segfault).

Como o Asterisk foi compilado com debug habilitado obtive informações no
gdb do core dump após o segfault:

#0  OneWordFind (tablePtr=0x9bb0678, key=0x80c2 <Address 0x80c2 out of
bounds>) at hashtable.c:585
585     hashtable.c: Arquivo ou diretório não encontrado.
        in hashtable.c
(gdb) bt full
#0  OneWordFind (tablePtr=0x9bb0678, key=0x80c2 <Address 0x80c2 out of
bounds>) at hashtable.c:585
        hPtr = (hash_HashEntry_t *) 0xffffffff
#1  0x0063affd in uc_createcall (uc=0x9bb0620, extra=0) at
unicall/hashtable.h:144
        crn = 32962
#2  0x001bb509 in call_control (uc=0x9bb0620, op=1, call=0x0,
data=0xb72a1f8c) at mfcr2.c:3651
No locals.
#3  0x0063bd71 in uc_call_control (uc=0x9bb0620, op=1, crn=0,
data=0xb72a1f8c) at unicall.c:593
        call = (uc_call_t *) 0x16
#4  0x0032a1a1 in unicall_call (ast=0xa3fb008, rdest=0xb66bb2c4
"g2/2090", timeout=0) at chan_unicall.c:1119
        p = (struct unicall_pvt *) 0x9baf250
        callparms = (uc_callparms_t *) 0xa457ab8
        callerid = "1234", '\0' <repeats 251 times>, "\b"
        dest = "g2/2090", '\0' <repeats 248 times>
        s = 0x0
        c = 0xb66bb2c7 "2090"
        n = 0x0
        l = 0xb72a209c "1234"
        ret = 6681736
        makecall = {callparms = 0xa457ab8, crn = 0}
        __PRETTY_FUNCTION__ = "unicall_call"
#5  0x0806b58d in ast_call (chan=0xa3fb008, addr=0xb66bb2c4 "g2/2090",
timeout=0) at channel.c:2638
        res = -1
        __PRETTY_FUNCTION__ = "ast_call"
#6  0x0806ad44 in __ast_request_and_dial (type=0xb66bb1c4 "UniCall",
format=64, data=0xb66bb2c4, timeout=30000, outstate=0xb72a244c,
    cid_num=0xb66bb7c8 "1234", cid_name=0xb66bb8c8 "", oh=0xb72a2394) at
channel.c:2471
        state = 0
        cause = 0
        chan = (struct ast_channel *) 0xa3fb008
        f = (struct ast_frame *) 0x8135120
        res = 0
        __PRETTY_FUNCTION__ = "__ast_request_and_dial"
#7  0x08098423 in ast_pbx_outgoing_exten (type=0xb66bb1c4 "UniCall",
format=64, data=0xb66bb2c4, timeout=30000,
    context=0xb66bb6c4 "testes_ramal", exten=0xb66bb5c4 "*200",
priority=1, reason=0xb72a244c, sync=2, cid_num=0xb66bb7c8 "1234",
    cid_name=0xb66bb8c8 "", vars=0x0, account=0xb66bb9c8 "",
channel=0x0) at pbx.c:5019
        chan = (struct ast_channel *) 0x9d6e080
        as = (struct async_stat *) 0x0
        res = -1
        cdr_res = -1
        oh = {context = 0xb66bb6c4 "testes_ramal", exten = 0xb66bb5c4
"*200", priority = 1, cid_num = 0xb66bb7c8 "1234",
  cid_name = 0xb66bb8c8 "", account = 0xb66bb9c8 "", vars = 0x0,
parent_channel = 0x0}
        attr = {__size =
"SIP/2055\000$*·È\217\213\000St\214\000å\001\000\000°\211\214\000½\211\214\000SIP/",
__align = 793790803}
        __PRETTY_FUNCTION__ = "ast_pbx_outgoing_exten"
#8  0x0065d09f in attempt_thread (data=0xb66bb0b0) at pbx_spool.c:266
        o = (struct outgoing *) 0xb66bb0b0
        res = 0
---Type <return> to continue, or q <return> to quit---
        reason = 10996712
        __PRETTY_FUNCTION__ = "attempt_thread"
#9  0x00a7d3b6 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#10 0x007f133e in clone () from /lib/libc.so.6
No symbol table info available.


Este mesmo erro já foi reportado por outro usuário:

http://lists.digium.com/pipermail/asterisk-users/2007-February/180020.html

E também por mim:

http://listas.asteriskbrasil.org/pipermail/asteriskbrasil/2007-June/015054.html


Pergunta ao pessoal do Disc-OS:

Vocês pretendem prestar manutenção no UniCall já que agora a Intelbrás
vende uma placa de E1 que precisa dele ? Pretendem tentar corrigir erros
desse tipo ? O que acham de integrar as melhorias que fizeram com a
versões oficiais ? Quem sabe até assumir oficialmente a manutenção do
chan_unicall no Asterisk já que o autor (Steve Underwood) está mais
ligado ao Callweaver atualmente do que ao Asterisk ?

A todos:

alguém já teve esse erro antes ? Conseguiu resolver de algum modo ?

Neste teste de carga o segfault ocorreu após 14 horas de teste mas nos
PABX de produção com tráfego médio o segfault ocorre a cada 1 ou 2
semanas. O problema não é "extremamente" crítico mas é grave pois todas
as ligações ativas no momento são desligadas.

Para efeito de comparação: nos PABX que tem somente E1 ISDN/PRI o
Asterisk tem uptime de meses e só é interrompido para manutenções
programadas.



  Leonardo