Segfault libpthread-2.9.so
18 views
Skip to first unread message
TxivaSad
Nov 25, 2010, 5:33:49 AM11/25/10
to asterisk-es-rsp
Hola
Hace tiempo que tengo un segfault que se me escapa y que no podía
reproducir. Hoy por fin le he dedicado algo de tiempo y lo he
conseguido reproducir en la centralita de la oficina
Nov 25 11:24:21 OptiTwin kernel: [1193706.456051] asterisk[20276]:
segfault at 10 ip 00007fdbe0943a2a sp 00007fdbc22c07b0 error 4 in
libpthread-2.9.so[7fdbe093b000+17000]
Entra una llamada en una cola o directamente a una extensión A
La extensión A se la pasa a B con transferencia atendida.
Hablan y la extensión B se la pasa otra vez a A con atendida.
El segfault se produce después de que B le de a transfer otra vez.
Voy compilar con DONT-OPTIMIZE y demás a ver si tengo más info.
Hace tiempo que tengo un segfault que se me escapa y que no podía
reproducir. Hoy por fin le he dedicado algo de tiempo y lo he
conseguido reproducir en la centralita de la oficina
Nov 25 11:24:21 OptiTwin kernel: [1193706.456051] asterisk[20276]:
segfault at 10 ip 00007fdbe0943a2a sp 00007fdbc22c07b0 error 4 in
libpthread-2.9.so[7fdbe093b000+17000]
Entra una llamada en una cola o directamente a una extensión A
La extensión A se la pasa a B con transferencia atendida.
Hablan y la extensión B se la pasa otra vez a A con atendida.
El segfault se produce después de que B le de a transfer otra vez.
Voy compilar con DONT-OPTIMIZE y demás a ver si tengo más info.
TxivaSad
Nov 25, 2010, 12:22:41 PM11/25/10
to asterisk-es-rsp
Falsa alarma no es el segfault que buscaba...
es un problema con el SENDDTMF. He estado haciendo pruebas para enviar
digitos a un terminal y se ve que los polycom no les mola.
#0 0x00007ff26f5465fb in __ast_pthread_mutex_lock
(filename=0x7ff26f5a1d34 "chan_sip.c", lineno=3916,
func=0x7ff26f5a4310 "sip_senddigit_begin",
mutex_name=0x7ff26f5a2cde "&p->lock", t=0x0) at /usr/src/sources/
asterisk-es-rsp/asterisk/1.4.24.1/asterisk-1.4.24.1_dev/include/
asterisk/lock.h:351
#1 0x00007ff26f551751 in sip_senddigit_begin (ast=0xb15a70, digit=42
'*') at chan_sip.c:3916
#2 0x000000000044f6ea in ast_senddigit_begin (chan=0xb15a70, digit=42
'*') at channel.c:2679
#3 0x000000000044f88d in ast_senddigit (chan=0xb15a70, digit=42 '*')
at channel.c:2715
#4 0x000000000041ebd7 in ast_dtmf_stream (chan=0xb15a70, peer=0x0,
digits=0x7ff25edcc720 "*#", between=250) at app.c:252
#5 0x00007ff26d2c93cf in senddtmf_exec (chan=0xb15a70,
data=0x7ff25edced10) at app_senddtmf.c:84
#6 0x000000000049a6ca in pbx_exec (c=0xb15a70, app=0x7ff274031640,
data=0x7ff25edced10) at pbx.c:537
#7 0x000000000049e6e4 in pbx_extension_helper (c=0xb15a70, con=0x0,
context=0xb15e10 "ext-oficina", exten=0xb15e60 "h", priority=1,
label=0x0,
callerid=0xb28ca0 "209", action=E_SPAWN) at pbx.c:1863
#8 0x000000000049fcdb in ast_spawn_extension (c=0xb15a70,
context=0xb15e10 "ext-oficina", exten=0xb15e60 "h", priority=1,
callerid=0xb28ca0 "209")
at pbx.c:2370
#9 0x00000000004a0f0c in __ast_pbx_run (c=0xb15a70) at pbx.c:2610
#10 0x00000000004a135c in pbx_thread (data=0xb15a70) at pbx.c:2686
#11 0x00000000004ec910 in dummy_start (data=0xb10d90) at utils.c:856
#12 0x00007ff27ca253ba in start_thread () from /lib/libpthread.so.0
#13 0x00007ff27c0b802d in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
La instrucción que lo destruye todo, por si alguien quiere probar:
exten => h,1,SendDTMF(*#)
es un problema con el SENDDTMF. He estado haciendo pruebas para enviar
digitos a un terminal y se ve que los polycom no les mola.
#0 0x00007ff26f5465fb in __ast_pthread_mutex_lock
(filename=0x7ff26f5a1d34 "chan_sip.c", lineno=3916,
func=0x7ff26f5a4310 "sip_senddigit_begin",
mutex_name=0x7ff26f5a2cde "&p->lock", t=0x0) at /usr/src/sources/
asterisk-es-rsp/asterisk/1.4.24.1/asterisk-1.4.24.1_dev/include/
asterisk/lock.h:351
#1 0x00007ff26f551751 in sip_senddigit_begin (ast=0xb15a70, digit=42
'*') at chan_sip.c:3916
#2 0x000000000044f6ea in ast_senddigit_begin (chan=0xb15a70, digit=42
'*') at channel.c:2679
#3 0x000000000044f88d in ast_senddigit (chan=0xb15a70, digit=42 '*')
at channel.c:2715
#4 0x000000000041ebd7 in ast_dtmf_stream (chan=0xb15a70, peer=0x0,
digits=0x7ff25edcc720 "*#", between=250) at app.c:252
#5 0x00007ff26d2c93cf in senddtmf_exec (chan=0xb15a70,
data=0x7ff25edced10) at app_senddtmf.c:84
#6 0x000000000049a6ca in pbx_exec (c=0xb15a70, app=0x7ff274031640,
data=0x7ff25edced10) at pbx.c:537
#7 0x000000000049e6e4 in pbx_extension_helper (c=0xb15a70, con=0x0,
context=0xb15e10 "ext-oficina", exten=0xb15e60 "h", priority=1,
label=0x0,
callerid=0xb28ca0 "209", action=E_SPAWN) at pbx.c:1863
#8 0x000000000049fcdb in ast_spawn_extension (c=0xb15a70,
context=0xb15e10 "ext-oficina", exten=0xb15e60 "h", priority=1,
callerid=0xb28ca0 "209")
at pbx.c:2370
#9 0x00000000004a0f0c in __ast_pbx_run (c=0xb15a70) at pbx.c:2610
#10 0x00000000004a135c in pbx_thread (data=0xb15a70) at pbx.c:2686
#11 0x00000000004ec910 in dummy_start (data=0xb10d90) at utils.c:856
#12 0x00007ff27ca253ba in start_thread () from /lib/libpthread.so.0
#13 0x00007ff27c0b802d in clone () from /lib/libc.so.6
#14 0x0000000000000000 in ?? ()
La instrucción que lo destruye todo, por si alguien quiere probar:
exten => h,1,SendDTMF(*#)
Saúl Ibarra Corretgé
Nov 25, 2010, 12:34:29 PM11/25/10
to asteris...@googlegroups.com
2010/11/25 TxivaSad <teleco...@gmail.com>:
LoL :-(
Puedes probar con una versión más nueva a ver si sucede?
--
/Saúl
http://saghul.net | http://sipdoc.net
TxivaSad
Dec 2, 2010, 4:06:14 AM12/2/10
to asterisk-es-rsp
A ver si tengo un momento. Es la centralita de mi oficina, tampoco les
puedo ir puteando tanto jeje.
De mientras abro otro hilo que tengo más marrones.
On 25 Nov, 18:34, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> 2010/11/25 TxivaSad <telecosil...@gmail.com>:
puedo ir puteando tanto jeje.
De mientras abro otro hilo que tengo más marrones.
On 25 Nov, 18:34, Saúl Ibarra Corretgé <sag...@gmail.com> wrote:
> 2010/11/25 TxivaSad <telecosil...@gmail.com>:
TxivaSad
Dec 2, 2010, 8:16:56 AM12/2/10
to asterisk-es-rsp
Ok sigo con este que es el que he podido reproducir. Con asterisk
1.4.37 pasa lo mismo, con lo que no es problema de la rsp.
Si la transferencia la hace un polycom o un aastra mata al sistema
pero si la hace un linksys no... ni idea. He mirado pero los tres los
tengo configurados con rfc2833.
Voy a ver si rescato mi inglés y lo subo al bugtracker.
Estoy mega emocionada. Tengo las siguientes opciones:
a) que sea un problema al marcar "*"
b) que haya algun conflicto con las opciones por defecto del features
y lo que yo le mando.
c) que sea la "h"
A ver si con un poco de surte resuelvo todos los problemas que tengo:
1) problemas con una centralita que usan el *+extension para la
megafonía y tienen polycom
2) problemas con otra que usan el *+extension para el pickup y tienen
aastras
3) problemas con otra que envian un *# a ciertos teléfonos y tienen
polycom
Veo un patrón, o fantasmas, estoy que me salgo. Voy a probar más
combinaciones de digitos a ver si también me la cargo.
1.4.37 pasa lo mismo, con lo que no es problema de la rsp.
Si la transferencia la hace un polycom o un aastra mata al sistema
pero si la hace un linksys no... ni idea. He mirado pero los tres los
tengo configurados con rfc2833.
Voy a ver si rescato mi inglés y lo subo al bugtracker.
Estoy mega emocionada. Tengo las siguientes opciones:
a) que sea un problema al marcar "*"
b) que haya algun conflicto con las opciones por defecto del features
y lo que yo le mando.
c) que sea la "h"
A ver si con un poco de surte resuelvo todos los problemas que tengo:
1) problemas con una centralita que usan el *+extension para la
megafonía y tienen polycom
2) problemas con otra que usan el *+extension para el pickup y tienen
aastras
3) problemas con otra que envian un *# a ciertos teléfonos y tienen
polycom
Veo un patrón, o fantasmas, estoy que me salgo. Voy a probar más
combinaciones de digitos a ver si también me la cargo.
Saúl Ibarra Corretgé
Dec 2, 2010, 8:29:17 AM12/2/10
to asteris...@googlegroups.com
2010/12/2 TxivaSad <teleco...@gmail.com>:
> Ok sigo con este que es el que he podido reproducir. Con asterisk
> 1.4.37 pasa lo mismo, con lo que no es problema de la rsp.
> Si la transferencia la hace un polycom o un aastra mata al sistema
> pero si la hace un linksys no... ni idea. He mirado pero los tres los
> tengo configurados con rfc2833.
>
> Voy a ver si rescato mi inglés y lo subo al bugtracker.
>
> Estoy mega emocionada. Tengo las siguientes opciones:
> a) que sea un problema al marcar "*"
> b) que haya algun conflicto con las opciones por defecto del features
> y lo que yo le mando.
> c) que sea la "h"
>
> Ok sigo con este que es el que he podido reproducir. Con asterisk
> 1.4.37 pasa lo mismo, con lo que no es problema de la rsp.
> Si la transferencia la hace un polycom o un aastra mata al sistema
> pero si la hace un linksys no... ni idea. He mirado pero los tres los
> tengo configurados con rfc2833.
>
> Voy a ver si rescato mi inglés y lo subo al bugtracker.
>
> Estoy mega emocionada. Tengo las siguientes opciones:
> a) que sea un problema al marcar "*"
> b) que haya algun conflicto con las opciones por defecto del features
> y lo que yo le mando.
> c) que sea la "h"
>
Tiene pinta de ser la h, no se en qué estado se encuentra el channel
en ese momento... intentar eso debería generar un warning y ser
ignorado IMHO...
jose luis millan
Dec 6, 2010, 10:54:22 AM12/6/10
to asteris...@googlegroups.com
Una pregunta Silvia;
¿puede ser que la definición del contexto en cuestión esté detrás de
un 'switch'?
Un saludo
2010/12/2 Saúl Ibarra Corretgé <sag...@gmail.com>:
> --
> Has recibido este mensaje porque estás suscrito al grupo "asterisk-es-rsp" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a asteris...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a asterisk-es-r...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/asterisk-es-rsp?hl=es.
>
>
TxivaSad
Dec 13, 2010, 10:11:52 AM12/13/10
to asterisk-es-rsp
No en este caso es tal cual:
sip.conf context=test
[test]
exten => _X.,1,Dial(SIP/${EXTEN},,)
exten => _X.,n,Hangup
exten => h,1,SentDtmf("123")
y se muere igual.
On 6 Des, 16:54, jose luis millan <doctor...@gmail.com> wrote:
> Una pregunta Silvia;
>
> ¿puede ser que la definición del contexto en cuestión esté detrás de
> un 'switch'?
>
> Un saludo
>
> 2010/12/2 Saúl Ibarra Corretgé <sag...@gmail.com>:
>
> > 2010/12/2 TxivaSad <telecosil...@gmail.com>:
sip.conf context=test
[test]
exten => _X.,1,Dial(SIP/${EXTEN},,)
exten => _X.,n,Hangup
exten => h,1,SentDtmf("123")
y se muere igual.
On 6 Des, 16:54, jose luis millan <doctor...@gmail.com> wrote:
> Una pregunta Silvia;
>
> ¿puede ser que la definición del contexto en cuestión esté detrás de
> un 'switch'?
>
> Un saludo
>
> 2010/12/2 Saúl Ibarra Corretgé <sag...@gmail.com>:
>
jose luis millan
Dec 13, 2010, 10:15:20 AM12/13/10
to asteris...@googlegroups.com
Supongo que la aplicación de la extensión h es "SendDtmf", verdad?
2010/12/13 TxivaSad <teleco...@gmail.com>:
TxivaSad
Dec 14, 2010, 4:52:35 AM12/14/10
to asterisk-es-rsp
jajajaja si
On 13 Des, 16:15, jose luis millan <doctor...@gmail.com> wrote:
> Supongo que la aplicación de la extensión h es "SendDtmf", verdad?
>
> 2010/12/13 TxivaSad <telecosil...@gmail.com>:
On 13 Des, 16:15, jose luis millan <doctor...@gmail.com> wrote:
> Supongo que la aplicación de la extensión h es "SendDtmf", verdad?
>
jose luis millan
Dec 14, 2010, 4:53:09 AM12/14/10
to asteris...@googlegroups.com
;)
2010/12/14 TxivaSad <teleco...@gmail.com>:
jose luis millan
Dec 14, 2010, 4:57:03 AM12/14/10
to asteris...@googlegroups.com
¿Tienes a mano la salida de 'bt full' de gdb?
2010/12/14 jose luis millan <doct...@gmail.com>:
Gustavo B
Dec 15, 2010, 4:45:37 PM12/15/10
to asteris...@googlegroups.com
Hola... con un grupo de colegas realizamos un stress test sobre la version 1.4.37 y la verdad que funcionó muy bien... en mi blog hay un detalle de las pruebas que hicimos, por si les interesa.
Salduos!
Gustavo Borgoni
http://asteriskhelp.blogspot.com
Reply all
Reply to author
Forward
0 new messages