Summary:	ASTERISK-07164: [patch] Asterisk crashes on AddQueueMember with local channel
Reporter:	jmls (jmls)	Labels:
Date Opened:	2006-06-14 06:57:06	Date Closed:	2006-06-16 07:50:44
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) fix_queue_local_crash.patch.txt
Description:	If you AddQueueMember(SomeQ|Local/706) then asterisk will crash with a segfault ****** ADDITIONAL INFORMATION ****** The above construct is probably incorrect, as you need to specify an @context, as in AddQueueMember(SomeQ|Local/706@context), but asterisk should generate an error, not segfault. I think it's a crash / major bug but don't want to be flamed :)
Comments:	By: Serge Vecher (serge-v) 2006-06-14 08:43:56 you will be flamed for not reading the BUG GUIDELINES -- all crashes must be accompanied by a backtrace from non-optimized build. Also, what modifications have you done to the source? By: jmls (jmls) 2006-06-14 10:08:02 Whoa! Sorry. I didn't want to report it as major or a crash because there is a simple workaround. Add the correct parameters. No modifications to app_queue whatsover. Why do you ask ? I was am preparing to produce the backtrace. I simply wanted to get this posted as soon as possible because of the upcoming release. To simply rebuild an non-optimized asterisk on a box that is being used by a load of people for testing (asterisk svn trunk) is not as quick as you would like. By: Serge Vecher (serge-v) 2006-06-14 10:17:14 1. I've asked about modifications to the source, because sometimes the mods are the problem, not the standard Asterisk code ;) 2. As soon as you upload the backtrace, I will mark the issue as new again. By: jmls (jmls) 2006-06-14 10:25:38 do you want any of the new snazzy compiler flags set in menuselect ? (Apart from DONT_OPTIMIZE) By: Serge Vecher (serge-v) 2006-06-14 10:31:19 no -- only DONT_OPTIMIZE. Thanks By: jmls (jmls) 2006-06-14 10:42:50 ok, sorry, I am not a C person: what does this mean: -rw-------  1 root root 13254656 Jun 14 16:40 core.3294 [root@foxtrot tmp]# gdb core.3294 GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"..."/tmp/core.3294": not in executable format: File format not recognized I cannot get a stack trace because the file format is not recognised By: Terry Wilson (twilson) 2006-06-14 11:25:24 Looks like pbx.c is doing a strcmp on context without checking if it exists.  the attached patch fixes the problem.  Disclaimer on file. By: jmls (jmls) 2006-06-14 11:32:16 that patch works on my system. Thanks By: Terry Wilson (twilson) 2006-06-14 11:38:37 np.  There is one other line in pbx_find_extension where context is strcasecmp'd without being checked.  It is within a for loop that apparently we aren't hitting with this case.  It seems like the best thing to do would be to set context to 'default' if it isn't set, but context is const char* and I don't like making changes to pbx.c if I can help it. By: jmls (jmls) 2006-06-14 12:06:18 do you still need the backtrace ? By: Serge Vecher (serge-v) 2006-06-14 12:08:45 Not at this point, since twilson has already figured the problem out. Only need the bt to figure out where the crash was and under what conditions. Thanks. By: BJ Weschke (bweschke) 2006-06-16 07:50:43 This should be fixed now, but the patch I'm committing is in chan_local.c on the check of the devicestate which is calling the code in pbx.c that's segfaulting. We'll quit early now from that if we detect that the channel is improperly defined and through a warning to the CLI.