aboutsummaryrefslogtreecommitdiffstats
path: root/main/pbx.c
AgeCommit message (Collapse)AuthorFilesLines
2008-06-04Fix a log message and add a message for when the dialplan is done reloading.file1-1/+1
(closes issue #12716) Reported by: chappell Patches: dialplan_reload_2.diff uploaded by chappell (license 8) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120282 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-08Don't use a channel before checking for channel allocation failure.russell1-6/+6
(closes issue #12609) Reported by: edantie git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115551 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-23Instead of stopping dialplan execution when SayNumber attempts to say a ↵file1-1/+6
large number that it can not print out a message informing the user and continue on. (closes issue #12502) Reported by: bcnit git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114579 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-11It's possible that a channel can have an async goto on the successful ↵qwell1-2/+4
execution of an application as well. Closes issue #12172. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114072 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-27These small documentation updates made in response to a query inmurf1-0/+3
asterisk-users, where a user was using Playback, but needed the features of Background, and had no idea that Background existed, or that it might provide the features he needed. I thought the best way to avert these kinds of queries was to provide "See Also" references in all three of "Background", "Playback", "WaitExten". Perhaps a project to do this with all related apps is in order. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@111391 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-10Use non-global storage for eswitchtilghman1-11/+12
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107230 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-10Fix another bug specifically related to asynchronous call origination. Once therussell1-1/+1
PBX is started on the channel using ast_pbx_start(), then the ownership of the channel has been passed on to another thread. We can no longer access it in this code. If the channel gets hung up very quickly, it is possible that we could access a channel that has been free'd. (inspired by BE-386) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107161 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-10Fix some bugs related to originating calls. If the code failed to start a PBXrussell1-1/+8
on the channel (such as if you set a call limit based on the system's load average), then there were cases where a channel that has already been free'd using ast_hangup() got accessed. This caused weird memory corruption and crashes to occur. (fixes issue BE-386) (much debugging credit goes to twilson, final patch written by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@107158 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Quell an annoying message that is likely to print every single time that mmichelson1-3/+1
ast_pbx_outgoing_app is called. The reason is that __ast_request_and_dial allocates the cdr for the channel, so it should be expected that the channel will have a cdr on it. Thanks to joetester on IRC for pointing this out git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106437 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-04Backport a minor bug fix from trunk that I found while doing random coderussell1-6/+10
cleanup. Properly break out of the loop when a context isn't found when verify that includes are valid. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105591 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-28Make pbx_exec pass an empty string into applications, if we get NULL.qwell1-2/+2
This protects against possible segfaults in applications that may try to use data before checking length (ast_strdupa'ing it, for example) (closes issue #12100) Reported by: foxfire Patches: 12100-nullappargs.diff uploaded by qwell (license 4) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105005 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-31closes issue #11845; that's the one where there's a 1004 byte cdr leak with ↵murf1-1/+2
every AMI Redirect to a zap channel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@101480 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-28WaitExten didn't handle AbsoluteTimeout properly (went to 't' instead of 'T')tilghman1-1/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100675 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-31Avoiding a potentially bad locking situation. ast_merge_contexts_and_delete ↵mmichelson1-1/+2
writelocks the conlock, then calls ast_hint_extension, which attempts to readlock the same lock. Recursion with read-write locks is dangerous, so the inner lock needs to be removed. I did this by copying the "guts" of ast_hint_extension into ast_merge_contexts_and_delete (sans the extra lock). (this change is inspired by the locking problems seen in issue #11080, but I have no idea if this is the problematic area experienced by the reporters of that issue) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@95577 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-27Now that the contexts lock is a read/write lock, it should not be locked hererussell1-2/+0
in ast_hint_state_changed(). This makes it get locked recursively which now causes a deadlock. (closes issue #11080, thanks to callguy for the access to a deadlocked machine) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94831 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-21Convert the contexts lock to a read/write lock to resolve a deadlock. Thisrussell1-31/+48
has a nice side benefit of improving performance. :) (closes issue #11609) (closes issue #11080) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94466 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-13Make application help text a little more clear about the use of extensions ↵qwell1-7/+7
in a filename. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@92809 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-04Make some changes to some additions I made recently for doing channel ↵russell1-19/+9
autoservice when looking up extensions. This code was added to handle the case where a dialplan switch was in use that could block for a long time. However, the way that I added it, it did this for all extension lookups. However, lookups in the in-memory tree of extensions should _not_ take long enough to matter. So, move the autoservice stuff to be only around executing a switch. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90967 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-28Removing some seemingly pointless code. This sets a channel variable for ↵mmichelson1-6/+0
every priority executed in the dialplan if you have debug set to anything non-zero. This seems pointless due to the fact that these channel variables are not referenced anywhere else in the code and their names are esoteric enough that they would not be practical to reference in the dialplan. Plus the fact that this behavior isn't documented anywhere means that the change is not likely to cause any disruption. If anything, this may actually cause a slight performance increase if running with debug on. The motivating influence for this code change is the eventwhencalled option for queues. If set to vars, all channel variables will be output to the manager. These unnecessary channel variables make the output a lot more difficult to deal with. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90059 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-28 - update documentation for some of the goto functions to note that theyrussell1-0/+4
handle locking the channel as needed - update ast_explicit_goto() to lock the channel as needed git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89893 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-27Don't start/stop autoservice in pbx_extension_helper() unless a channel existsrussell1-8/+16
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89839 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-27Merge changes from team/russell/autoservice_1.4russell1-3/+20
This set of changes fixes an issue that was reported to me on IRC yesterday. The user, d1mas, was using chan_zap for incoming calls and was having DTMF recognition issues in some situations. Specifically, he noticed that the problem occurred when using DISA or WaitExten. He also noticed that when using Read, the problem did not occur. His system also used DUNDi for dialplan lookups. So, he theorized that if the DUNDi lookups blocked for some period of time, that audio from the zap channel could get lost. If the audio got lost, then it wouldn't be run through the DTMF detector, and digits could get lost. He was correct, and the following set of changes fixes the problem. However, the changes go a little bit further than what was necessary to fix this exact problem. 1) I updated pbx_extension_helper() to autoservice the associated channel to handle cases where extension lookups may take a long time. This would normally be a dialplan switch that does some lookup over the network, such as the DUNDi or IAX2 switches. This ensures that even while a DUNDi lookup is blocking, the channel will be continuously serviced. 2) I made a change to the autoservice code. This is actually something that has bothered me for a long time. When a channel is in autoservice, _all_ frames get thrown away. However, some frames really shouldn't be thrown away. The most notable examples are signalling (CONTROL) frames, and DTMF. So, this patch queues up important frames while a channel is in autoservice. When autoservice is stopped on the channel, the queued up frames get stuck back on the channel so that they can get processed instead of thrown away. 3) I made another change to the autoservice code to handle the case where autoservice is started on channels recursively. Previously, you could call ast_autoservice_start() multiple times on a channel, and it would stop the first time ast_autoservice_stop() gets called. Now, it will ensure that autoservice doesn't actually stop until the final call to ast_autoservice_stop(). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89790 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-26Add channel locking to a function that needed to be doing it. This is just arussell1-0/+2
little something I noticed while working on a completely unrelated issue. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89594 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-20According to comments in main/pbx.c, it is essential that if we are going to ↵mmichelson1-0/+2
lock the conlock as well as the hints lock, it must be locked in that respective order. In order to prevent a potential deadlock, we need to lock the conlock prior to locking the hints lock in ast_hint_state_changed (see the call stack example on issue #11323 for how this can happen). (closes issue #11323, reported by eelcob, suggestion for patch by eelcob, patch by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89457 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-12Fix a typo pointed out by De_Mon on #asterisk-devqwell1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89194 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-05After seeing crashes related to channel variables, I went looking around at therussell1-11/+37
ways that channel variables are handled. In general, they were not handled in a thread-safe way. The channel _must_ be locked when reading or writing from/to the channel variable list. What I have done to improve this situation is to make pbx_builtin_setvar_helper() and friends lock the channel when doing their thing. Asterisk API calls almost all lock the channel for you as necessary, but this family of functions did not. (closes issue #10923, reported by atis) (closes issue #11159, reported by 850t) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@88805 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-11A dollar sign by itself, not indicating a start of a variable or expression ↵tilghman1-2/+3
prematurely ends substitution (closes issue #10939) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85356 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-17(closes issue #10734)file1-1/+1
Reported by: asgaroth Instead of passing a NULL pointer into snprintf pass "". It makes Solaris much happier. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@82514 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-30(closes issue #10603)file1-0/+3
Reported by: jmls Patches: pbx.diff uploaded by jmls (license 141) Backport changes from 81372. Add REASON dialplan variable for when an originated call fails and the failed extension is executed. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@81375 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-24Make the deprecation warning inline with the code, instead of only in ↵tilghman1-1/+6
documentation (closes issue #10549) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80747 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-17(closes issue #10209)russell1-0/+2
Reported by: juggie Patches: 10209-trunk-2.patch uploaded by juggie Tested by: juggie, blitzrage In ast_pbx_run(), mark a channel as hung up after an application returned -1, or when it runs out of extensions to execute. This is so that code can detect that this channel has been hung up for things like making sure DeadAGI is used on actual dead channels, and is beneficial for other things, like making sure someone doesn't try to start spying on a channel that is about to go away. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@75403 f38db490-d61c-443f-a65b-d21fe96a405b
2007-06-14use ast_localtime() in every place localtime_r() was being usedkpfleming1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@69392 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-14As per 9570, worrisome CDR warnings have been removed, that are either not ↵murf1-15/+1
helpful, or not relevant. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@64193 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-02Merged revisions 62737 via svnmerge from murf1-1/+1
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r62737 | murf | 2007-05-02 14:10:32 -0600 (Wed, 02 May 2007) | 1 line Some tweaks to satisfy CDR bug 8796, where being in 'h' extension louses up the dst field ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@62738 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-02a)In chan_zap, set the clid, src fields in channel_alloc call. b)in the ↵murf1-1/+1
channel_alloc func, set the cid_num and name fields from the arglist[blush]. c) don't update the channel app & app data fields if you are in the 'h' extension. d)the load_module func in cdr_radius needs to return DECLINE, SUCCESS. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@62689 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-27If no variables were passed into pbx_substitute_variables_helper_full(), thenrussell1-1/+1
don't even bother creating a temporary bogus channel, since that is only for allowing certain functions to operate on the variables as if they were on a channel. Most importantly, this fixes a crash. (issue #9613, reported by callguy, fixed by me) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@62171 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-23Some dialplan functions, such as CUT(), expect to operate on variables on arussell1-1/+15
channel. So, this little hack lets them work in places where a channel doesn't exist, such as within DUNDi configuration. (issue #9465, reported and patched by Corydon76, testing by blitzrage) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@61765 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-09This is a big improvement over the current CDR fixes. It may still need ↵murf1-3/+3
refinement, but this won't have as many folks bothered. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@60989 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-30several changes via kpflemings reviewmurf1-5/+0
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@59522 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-30These mods fix CDR issues from 8221, 8593, 8680, 8743, and perhaps others. ↵murf1-1/+7
Mainly with CDRs generated from transfer situations. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@59486 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-16Making these documentation changes in the 1.4 branch upset various people, sorussell1-56/+0
these chanes will only be done in the trunk. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@58955 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-15Refashion dump command to match common syntax and update the resulting ↵tilghman1-4/+4
appdocs TeX file git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@58946 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-15Expand deprecation warnings from simply warning on use to the builtin ↵tilghman1-0/+4
documentation. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@58939 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-15Merge changes from svn/asterisk/team/russell/LaTeX_docs.russell1-0/+56
* Convert most of the doc directory into a single LaTeX formatted document so that we can generate a PDF, HTML, or other formats from this information. * Add a CLI command to dump the application documentation into LaTeX format which will only be include if the configure script is run with --enable-dev-mode. * The PDF turned out to be close to 1 MB, so it is not included. However, you can simply run "make asterisk.pdf" to generate it yourself. We may include it in release tarballs or have automatically generated ones on the web site, but that has yet to be decided. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@58931 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-05Merged revisions 57825 via svnmerge from murf1-1/+1
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r57825 | murf | 2007-03-05 07:53:57 -0700 (Mon, 05 Mar 2007) | 1 line Fixed a typo introduced via 9156 (either the gotos or their doc strings are wrong) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@57826 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-02Merged revisions 57458 via svnmerge from murf1-9/+20
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r57458 | murf | 2007-03-02 09:39:33 -0700 (Fri, 02 Mar 2007) | 1 line further refinement in wording of goto documentation, as per 9156, goto not proceeding to next instruction ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@57473 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-28Merged revisions 57118 via svnmerge from murf1-2/+13
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r57118 | murf | 2007-02-28 12:12:41 -0700 (Wed, 28 Feb 2007) | 1 line a small documentation update, to reflect reality in the goto doc strings, as per 9156, Goto does not proceed to next prio if jump fails ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@57139 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-26Use ast_strlen_zero to see if the language and/or context argument is not ↵file1-2/+2
present for Background instead of just checking if it is NULL. (issue #9141 reported by mjagdis) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@56805 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-01Merged revisions 53069 via svnmerge from tilghman1-2/+1
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r53069 | tilghman | 2007-02-01 13:13:53 -0600 (Thu, 01 Feb 2007) | 2 lines No wonder FIELDQTY doesn't work with functions... the documentation in pbx.c was wrong ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@53070 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-31Merged revisions 53045 via svnmerge from russell1-0/+7
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r53045 | russell | 2007-01-31 15:25:11 -0600 (Wed, 31 Jan 2007) | 3 lines Fix a bunch of places where pthread_attr_init() was called, but pthread_attr_destroy() was not. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@53046 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-25 03:24:10 +0000