[asterisk-users] dialplan is not finding my number asterisk 1.8.3

[Steve Murphy]

Oh, you are *not* going to like this, but....

you have a few different paths:

1. If the dialplan stuff is not really a memory corruption, but some sort of
unplanned,
    but maybe accidentally programmed thing, either by you or something in
the asterisk
    code, then:

a. compile asterisk for debug. You can get in the menuselect stuff and make
sure
    the debug compile options are turned on. Install it.
b. Shut down asterisk
c. fire it back up, under gdb:

      gdb <full path to asterisk>
      br ast_context_remove_extension_callerid2
      comm 1
         where
         c
         end
      run <normal arguments to asterisk>

Then use asterisk as normal and wait for the problem to re-occur. Look to
see if any
calls to ast_context_remove_extension_callerid2 occurred (they will occur
with dial reloads-- lots of them).
You'll have to search carefully! The gdb messages could be buried in your
console output.

If the problem reoccurs, but you didn't see any calls to
ast_context_remove_extension_callerid2,
then it could be assumed that you are suffering some sort of memory
corruption.
Where it dies, or things start looking strange, may not indicate where or
why the corruption is
happening. In such a case, it really gets tricky to debug. Then we might
resort to
stuff like dmalloc, and others, to help spot where/when corruption occurs.
Let's cross that
bridge if we come to it.

murf


On Tue, Apr 5, 2011 at 7:30 AM, Jerry Geis <geisj at pagestation.com> wrote:

> Jerry Geis wrote:
>
>>
>> Steve Murphy wrote:
>>
>>> Idea:
>>>
>>> If something is corrupting your dialplan, then this should
>>> reveal the extent of the corruption:
>>>
>>> You might, when the system is working properly, do a:
>>>
>>> asterisk -rx "dialplan show" > somefile1
>>>
>>> and then, when you are having problems, do a:
>>>
>>> asterisk -rx "dialplan show" > somefile2
>>> diff -u somefile1 somefile2
>>>
>>> and see if this reveals anything juicy.
>>>
>>> murf
>>>
>>>
>> Steve,
>>
>> That is a great idea. I did that the first time it happened. I dumped the
>> dialplan, then I restarted
>> and dumped again. it was the same. Being the first time I thought it was
>> just a fluke but now it
>> has happened a couple of times. I have not been able to narrow anything
>> down.
>>
>> Thanks,
>>
>> jerry
>>
>>  Steve,
>
> perhaps I did something wrong the first time. As I just got the error
> again. I dumped the dialplan and my section:
>
>
> [ Context 'smvoice-mediaport' created by 'pbx_config' ]
>
> is empty.
>
> when I restart and dump again.
>
>
> [ Context 'smvoice-mediaport' created by 'pbx_config' ]
>  '1105' =>         1. Goto(smvoice-mediaport-public-address,s,1)
> [pbx_config]
>  'mediaport_direct' => 1. Goto(smvoice-mediaport-public-address,s,1)
> [pbx_config]
>  'public_address' => 1. Goto(smvoice-mediaport-public-address,s,1)
> [pbx_config]
>
> I have the correct data.
>
> The only thing I have in the dialplan for this box is:
>
> [smvoice-mediaport-public-address]
> exten => s,1,System(/home/silentm/bin/smfunctions -stop)
> exten => s,n,Playback(beep)
> exten => s,n,Dial(Console/dsp)
> exten => s,n,Hangup
> exten => h,1,System(/home/silentm/bin/smfunctions -start)
>
> Can a system call be removing stuff from the dialplan?
>
> What next?
>
Oh, you are *not* going to like this, but....

you have a few different paths:

1. If the dialplan stuff is not really a memory corruption, but some sort of
unplanned,
    but maybe accidentally programmed thing, either by you or something in
the asterisk
    code, then:

a. compile asterisk for debug. You can get in the menuselect stuff and make
sure
    the debug compile options are turned on. Install it.
b. Shut down asterisk
c. fire it back up, under gdb:

      gdb <full path to asterisk>
      br ast_context_remove_extension_callerid2
      comm 1
         where
         c
         end
      run <normal arguments to asterisk>

Then use asterisk as normal and wait for the problem to re-occur. Look to
see if any
calls to ast_context_remove_extension_callerid2 occurred (they will occur
with dial reloads-- lots of them).
You'll have to search carefully! The gdb messages could be buried in your
console output.

If the problem reoccurs, but you didn't see any calls to
ast_context_remove_extension_callerid2,
then it could be assumed that you are suffering some sort of memory
corruption.
Where it dies, or things start looking strange, may not indicate where or
why the corruption is
happening. In such a case, it really gets tricky to debug. Then we might
resort to
stuff like dmalloc, and others, to help spot where/when corruption occurs.
Let's cross that
bridge if we come to it.

murf



>
> Jerry
>
>


-- 

Steve Murphy

ParseTree Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110405/732e3d00/attachment.htm>