|Summary:||ASTERISK-06513: **Unknown** channel preceeds crash|
|Date Opened:||2006-03-09 13:06:24.000-0600||Date Closed:||2006-05-08 17:38:52|
|Environment:||Attachments:||( 0) backtrace.txt|
|Description:||preceeded (I think) by appearence of **Unknown** channel|
#0 0x405992d7 in socket_process (thread=0x8173fc8) at strings.h:35
#1 0x405d3af8 in iaxpeer_function () from /usr/lib/asterisk/modules/chan_iax2.so
Cannot access memory at address 0x1
****** ADDITIONAL INFORMATION ******
Asterisk SVN--r built by root @ ec on a i686 running Linux on 2006-03-08 05:06:26 UTC
(My revision number is off a day - I already updated)
An odd channel (sometimes - since my troubles began) appears in show channels:
ec*CLI> show channels
Channel Location State Application(Data)
**Unknown** s@default:1 Down (None)
My dialplan doesn't have any way into the default context.
But anything that finds the way in should pass through anyway.
exten => s,1,Answer(1)
exten => s,2,Set(TIMEOUT(digit)=5)
exten => s,3,Set(TIMEOUT(response)=10)
exten => s,4,GoTo(mw-main,s,1)
Just for laughs strings like occur in many places.
|Comments:||By: jharragi (jharragi) 2006-03-09 13:22:37.000-0600|
I just got similar dump now on revision ANOW-49
and the 'strings occur in many places' comment referred to greping the core file.
By: Joshua C. Colp (jcolp) 2006-03-20 18:50:18.000-0600
Did you compile with make dont-optimize? If not, can you please do so and try to recreate this issue again? Some vital information may have been optimized out as your backtrace looks a little weird
By: jharragi (jharragi) 2006-03-23 22:55:05.000-0600
I had to switch to 1.2. I haven't seen this appear on this branch. It is not looking like I'll be able to check into this for awhile - so you may want to close this for now...
The compile was with the stock makefile.
By: Serge Vecher (serge-v) 2006-05-01 16:27:39
jharragi: is this still an issue? can you please provide a backtrace from a recent trunk?
Has anybody else experienced this issue?
By: Serge Vecher (serge-v) 2006-05-08 17:38:52
I will close the issue at this time. If you are able to reproduce the issue either with trunk or 1.2 branch, please upload a new non-optimized backtrace. Thanks and good luck.