Summary:	ASTERISK-20305: Asterisk crashing on Page()
Reporter:	Noah Engelberth (mlnoah)	Labels:
Date Opened:	2012-08-23 13:18:53	Date Closed:	2012-09-04 10:31:07
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_page
Versions:	SVN	Frequency of Occurrence
Related Issues:
Environment:	CentOS 6.3 on a Dell Optiplex 790 - Cisco SPA509G phones	Attachments:	( 0) ASTERISK-20305.patch ( 1) backtrace-auto-answer-and-self.txt ( 2) backtrace-auto-answer-no-self.txt ( 3) backtrace-no-auto-answer.txt ( 4) debug-auto-answer-and-self.txt ( 5) debug-auto-answer-no-self.txt ( 6) debug-no-auto-answer.txt
Description:	Asterisk crashes whenever I use the Page application to page 1 or more phones from one of my SIP handset.   My call to Page is as follows: exten => 398,1,Verbose(2,Page all phones) same => n,SIPAddHeader(Call-Info: <sip:172.16.19.1>\;answer-after=0) same => n,Page(SIP/649EF376C820,s,10) same => n,Hangup() I have replicated the crash under the following conditions: - Paging all phones (including the caller) via a Local/extension channel -- my test environment is a hotdesking environment, so my first attempt was to page by extension - Paging all phones (including the caller) via SIP/peer channels without the auto-answer SIP header (case no-auto-answer) - Paging all phones (including the caller) via SIP/peer channels with the auto-answer SIP header (case auto-answer-and-self) - Paging all phones except the caller via SIP/peer channels with the auto-answer SIP header (case auto-answer-no-self) - Paging one phone (as above), not the caller, via SIP/peer channel with the auto-answer SIP header Verbose 5 / Debug 5 logs attached as debug-*.txt BT attached as backtrace-*.txt
Comments:	By: Noah Engelberth (mlnoah) 2012-08-23 13:42:37.528-0500 Oh, forgot to mention I have no hardware cards at all in the system, and libpri/DAHDI are not compiled. By: Matt Jordan (mjordan) 2012-08-23 13:51:13.871-0500 This looks like an error in the configuration parsing of ConfBridge is causing the problem. Do you have a confbridge.conf available on the system?  If so, do you mind attaching it? If not, it shouldn't crash... but it might require that as part of the loading. By: Noah Engelberth (mlnoah) 2012-08-23 14:04:49.719-0500 Oops, now I feel brillant.  No, I did not have a confbridge.conf in /etc/asterisk as of the crashing. When I copied the sample confbridge.conf into /etc/asterisk and tried to run module reload app_confbridge.so, I got a notice: [Aug 23 14:57:31] NOTICE[14444]: loader.c:746 ast_module_reload: The module 'app_confbridge.so' was not properly initialized.  Before reloading the module, you must run "module load app_confbridge.so" and fix whatever is preventing the module from being initialized. When I tried to unload it, I got: testasterisk11*CLI> module unload app_confbridge.so Unable to unload resource app_confbridge.so Command 'module unload app_confbridge.so ' failed. [Aug 23 14:57:39] WARNING[14444]: loader.c:539 ast_unload_resource: Unload failed, 'app_confbridge.so' is not loaded. When I tried to load it, I got: testasterisk11*CLI> module load app_confbridge.so Unable to load module app_confbridge.so Command 'module load app_confbridge.so ' failed. [Aug 23 14:57:45] ERROR[14444]: pbx.c:3776 __ast_custom_function_register: Function CONFBRIDGE already registered. Ultimately, a service asterisk restart (after putting confbridge.conf in /etc/asterisk) got things up and running, Page() works as expected with SIP devices after putting that config file in place.  (The Local/extension is misbehaving at the moment, but I assume that's my configuration problem). By: Matt Jordan (mjordan) 2012-08-23 15:09:00.887-0500 Not your fault.  I would expect app_page to not load if it didn't have its dependency loaded, not crash. I'll test it out with the sample confbridge.conf.  The workflow you had is a little odd, but it sounds like the CONFBRIDGE function was registered during the reload when it shouldn't have been, since the module wasn't loaded already.  Then the module load operation later failed because the CONFBRIDGE function was already registered.  So that's a whole other separate wacky problem. By: Noah Engelberth (mlnoah) 2012-08-23 15:16:22.190-0500 Basically, I copied the confbridge.conf sample file into /etc/asterisk while asterisk was up and running (it had been started without the confbridge.conf file available).  I then tried to reload the module, short of restarting Asterisk, as described previously, none of which worked.  I did try a module load app_confbridge.so before trying reload, which gave me the exact same error as after I tried reload -- so then I tried reload, then unload and load as above. Completely restarting Asterisk did cause the ConfBridge application to load correctly. By: Mark Michelson (mmichelson) 2012-08-27 14:57:13.669-0500 There are two things that need to be fixed here. First, the new config options API needs to be more resilient in the face of unexpected circumstances. In this particular case, the app_confbridge passed in a structure with a NULL component where the config options API expected it to be non-NULL. This is the literal instruction that caused the crash in the first place. Underlying this, however, is the fact that app_confbridge did not load properly (due to a missing confbridge.conf file) but still registered the CONFBRIDGE function, the CONFBRIDGE_INFO function, and the Confbridge() dialplan application. This will be easy to fix for app_confbridge, but I have a fear that this type of behavior is more widespread than just in app_confbridge though. I'll likely open an issue to get this addressed more thoroughly throughout. By: Mark Michelson (mmichelson) 2012-08-27 16:13:11.429-0500 I'm uploading ASTERISK-20305.patch. This patch has fixed the problem locally for me. I've also placed the changes on review board at https://reviewboard.asterisk.org/r/2086 By: Noah Engelberth (mlnoah) 2012-08-29 10:07:54.048-0500 Applied the patch to SVN-branch-11-r371592, fixed the crash if app_confbridge.so was not loaded.  Also fixed that I can now issue module load app_confbridge.so in the case where Asterisk was started without /etc/asterisk/confbridge.conf and I then added the correct conf file to /etc/asterisk while asterisk was running.