Merged revisions 130145 via svnmerge from

https://origsvn.digium.com/svn/asterisk/trunk

Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which 
also solved problems with contexts having 
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.

Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
   (at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
   was forked, making special note of all revs that
   were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
   determine if it was involved in the merge_and_delete
   enhancements in trunk. 25 commits were done in 1.6.0,
   all but one (106306) was a merge from trunk.
   Trunk had 22 additional changes, of which 7 were
   involved in the merge_and_delete enhancements:
    106757
    108894
    109169
    116461
    123358
    130145
    130297
f. Go to trunk and collect patches, one by one,
   of the changes made by each rev across the
   entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and 
   resolve all failures and compilation problems
   before proceding to the next patch.
h. test the stuff.
i. profit!


........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines

(closes issue #13041)
Reported by: eliel
Tested by: murf

(closes issue #12960)
Reported by: mnicholson

In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.

I also added a lot of seemingly useless brackets
around single statement if's, which helped debug 
so much that I'm leaving them there.

I added a routine to check the correlation between
the extension tree lists and the hashtab 
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.

I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.

I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.

If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Steve Murphy
2008-07-15 13:14:07 +00:00
parent d962a11e55
commit e45d4f3bf1
23 changed files with 1936 additions and 1376 deletions

View File

@@ -520,7 +520,7 @@ static int load_module(void)
}
if (agi_loaded) {
con = ast_context_find_or_create(NULL, "app_stack_gosub_virtual_context", "app_stack");
con = ast_context_find_or_create(NULL, NULL, "app_stack_gosub_virtual_context", "app_stack");
if (!con) {
ast_log(LOG_ERROR, "Virtual context 'app_stack_gosub_virtual_context' does not exist and unable to create\n");
return AST_MODULE_LOAD_DECLINE;