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 <ge...@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
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users