This is the output of gdb:

Reading symbols from /usr/lib/asterisk/modules/cdr_pgsql.so...done.
Loaded symbols for /usr/lib/asterisk/modules/cdr_pgsql.so
Reading symbols from /usr/lib64/libpq.so.3...done.
Loaded symbols for /usr/lib64/libpq.so.3
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /usr/lib/asterisk/modules/chan_sccp.so...done.
Loaded symbols for /usr/lib/asterisk/modules/chan_sccp.so
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
#0 sccp_pbx_read (ast=0x0) at sccp_pbx.c:38
38 if (f->frametype == AST_FRAME_VOICE) {
(gdb)
(gdb)
(gdb)
(gdb)
(gdb) bt
#0 sccp_pbx_read (ast=0x0) at sccp_pbx.c:38
#1 0x0000000000416261 in ast_read (chan=0x6439f0) at channel.c:1337
#2 0x000000000041aa42 in ast_waitfordigit (c=0x6439f0, ms=2) at channel.c:1140
#3 0x0000002a9e326af1 in sccp_start_channel (data=0x0) at sccp_pbx.c:505
#4 0x0000002a95774c6b in start_thread () from /lib64/tls/libpthread.so.0
#5 0x0000002a95e8ce43 in thread_start () from /lib64/tls/libc.so.6
#6 0x0000000000000000 in ?? ()


Asterisk is bombing out on chan_sccp?

Thanks!


On Mon, 31 Jan 2005, Klaus-Peter Junghanns wrote:

Hi,

please start asterisk -vvvcg (so it creates a core file when it
segfaults), then run "gdb /usr/sbin/asterisk <corefile>", hit
Enter a few times and run a backtrace using "bt". Please email
the output. I doubt that it's bristuff bug, since many users
have already successfully upgraded.

best regards

Klaus

Am Montag, den 31.01.2005, 08:33 +0100 schrieb Remco Barende:
On Sun, 30 Jan 2005, Martin List-Petersen wrote:

Citat Remco Barende <[EMAIL PROTECTED]>:

I have Asterisk 1.0.5-BRIstuffed-0.2.0-RC5 up and running. Everything
seems to be running fine but after some time asterisk just goes crazy
(even withouth any incoming or outgoing call activity perviously).

If I leave the box up for some time * goes haywire and the console is
flooded with this message:
Ouch ... error while writing audio data: : Broken pipe

At that time I can see that there are multiple instances of mpg123 active.

The solution to this problem is to kill-9 mpg123, do the same for *,
unload the modules and then load the modules again and start asterisk. If
I do not unload re-load the modules I cannot access the ISDN line nor do
incoming calls work.

I really don't know where to look for this problem. Is it possible to
completely disable music on hold? Asterisk combined mpg123 is causing
nothing but problems anyway, the current stable still leaves abandoned
mpg123 processes.

It doesn't work :( Asterisk doesn't go haywire flooding the console but now simply bombs out with :

*CLI>
Segmentation fault

I guess that qualifies it as a bristuff bug?
_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users

_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to