dect
/
asterisk
Archived
13
0
Fork 0
Commit Graph

16 Commits

Author SHA1 Message Date
dvossel 7803be8ee4 fixes some memory leaks and redundant conditions
(closes issue #15269)
Reported by: contactmayankjain
Patches:
      patch.txt uploaded by contactmayankjain (license 740)
      memory_leak_stuff.trunk.diff uploaded by dvossel (license 671)
Tested by: contactmayankjain, dvossel




git-svn-id: http://svn.digium.com/svn/asterisk/trunk@201678 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-18 16:37:42 +00:00
murf 3122653ad6 Merged revisions 162264 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r162264 | murf | 2008-12-09 13:20:54 -0700 (Tue, 09 Dec 2008) | 1 line

In discussion with seanbright on #asterisk-dev,  I have added a default rule, and an option to suppress the default rule from being generated in the flex output, for the sake of those OS's where they didn't tweak flex's ECHO macro, and the compiler doesn't like it. The regressions are OK with this.
........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@162271 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09 20:40:31 +00:00
murf 7ef05745e7 Merged revisions 162136 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r162136 | murf | 2008-12-09 11:13:39 -0700 (Tue, 09 Dec 2008) | 1 line

Previous fix used ast_malloc and ast_copy_string and messed up the standalone stuff. Fixed.
........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@162140 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09 18:35:35 +00:00
murf 7806fa9c29 Merged revisions 162013 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r162013 | murf | 2008-12-09 09:31:55 -0700 (Tue, 09 Dec 2008) | 45 lines

(closes issue #14019)
Reported by: ckjohnsonme
Patches:
      14019.diff uploaded by murf (license 17)
Tested by: ckjohnsonme, murf

This crash was the result of a few small errors that
would combine in 64-bit land to result in a crash.

32-bit land might have seen these combine to mysteriously
drop the args to an application call, in certain
circumstances.

Also, in trying to find this bug, I spotted
a situation in the flex input, where, in passing
back a 'word' to the parser, it would allocate
a buffer larger than necessary. I changed the
usage in such situations, so that strdup was
not used, but rather, an ast_malloc, followed
by ast_copy_string.

I removed a field from the pval struct, in
u2, that was never getting used, and set in
one spot in the code. I believe it was an
artifact of a previous fix to make switch
cases work invisibly with extens.

And, for goto's I removed a '!' from
before a strcmp, that has been there
since the initial merging of AEL2, that
might prevent the proper target of a 
goto from being found. This was pretty
harmless on its own, as it would just
louse up a consistency check for users.

Many thanks to ckjohnsonme for providing
a simplified and complete set of information
about the bug, that helped considerably in
finding and fixing the problem.

Now, to get aelparse up and running again
in trunk, and out of its "horribly broken" state,
so I can run the regression suite!


........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@162079 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09 17:18:03 +00:00
kpfleming 601f6bcba7 don't blindly assume that Darwin and Cygwin need GLOB_ABORTED defined; only define it if it is not already defined
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@155121 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-06 22:49:19 +00:00
kpfleming cc1b2c100f bring over all the fixes for the warnings found by gcc 4.3.x from the 1.4 branch, and add the ones needed for all the new code here too
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@153616 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-02 18:52:13 +00:00
murf 98ba3dd3c0 Merged revisions 141094 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r141094 | murf | 2008-09-04 17:15:07 -0600 (Thu, 04 Sep 2008) | 70 lines

(closes issue #13357)
Reported by: pj
Tested by: murf

(closes issue #13416)
Reported by: yarns
Tested by: murf

If you find this message overly verbose, relax, it's probably
not meant for you. This message is meant for probably only
two people in the whole world: me, or the poor schnook that
has to maintain this code because I'm either dead or unavailable
at the moment.

This fix solves two reports, both having to do with embedding
a function call in a ${} construct. It was tricky because the
funccall syntax has parenthesis () in it. And up till now,
the 'word' token in the flex stuff didn't allow that, because
it would tend to steal the LP and RP tokens. To be truthful,
the "word" token was the trickiest, most unstable thing in
the whole lexer. I was lucky it made this long without complaints.
I had to choose every character in the pattern with extreme
care, and I knew that someday I'd have to revisit it. Well,
the day has come.

So, my brilliant idea (and I'm being modest), was to use the 
surrounding ${} construct to make a state machine and capture 
everything in it, no matter what it contains. But, I have to now
treat the word token like I did with comments, in that I turn
the whole thing into a state-machine sort of spec, with new
contexts "curlystate", "wordstate", and "brackstate".

Wait a minute, "brackstate"? Yes, well, it didn't take very many
regression tests to point out if I do this for ${} constructs,
I also have to do it with the $[] constructs, too.

I had to create a separate pcbstack2 and pcbstack3 because
these constructs can occur inside macro argument lists, and
when we have two state machines operating on the same structures
we'd get problems otherwise. I guess I could have stopped at
pcbstack2 and had the brackstate stuff share it, but it doesn't
hurt to be safe. So, the pcbpush and pcbpop routines also now
have versions for "2" and "3".

I had to add the {KEYWORD} construct to the initial pattern for
"word", because previously word would match stuff like "default7",
because it was a longer match than the keyword "default". But,
not any more, because the word pattern only matches only one or
two characters now, and it will always lose. So, I made it the
winner again by making an optional match on any of the keywords
before it's normal pattern.

I added another regression test to make sure we don't
lose this in future edits, and had to fix just one regression,
where it no longer reports a 'cascaded' error, which I guess
is a plus.

I've given some thought as to whether to apply these fixes to
1.4 and the 1.6.x releases, vs trunk; I decided to put it in
1.4 because one of the bug reports was against 1.4; and it
is unexpected that AEL cannot handle this situation. It actually
reduced the amount of useless "cascade" error messages that
appeared in the regressions (by one line, ehhem). There is
a possible side-effect in that it does now do more careful
checking of what's in those ${} constructs, as far as matching
parens, and brackets are concerned. Some users may find a an
insidious problem and correct it this way. This should be 
exceedingly rare, I hope.


........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@141115 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-04 23:31:41 +00:00
seanbright 1013afa1ad All of the res/ stuff (other than res_jabber) from the RSW branch.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@137028 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-10 00:47:56 +00:00
murf 64b640a6f7 Merged revisions 109309 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109309 | murf | 2008-03-18 00:37:15 -0600 (Tue, 18 Mar 2008) | 17 lines

(closes issue #11903)
Reported by: atis

Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.

Sorry for not solving this earlier. I got distracted.

Added the ntest23 regression test, which is mainly a copy of ntest22, 
but with a few juicy errors thrown in, to replicate the kind of 
error that atis spotted.



........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@109357 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-18 14:09:50 +00:00
murf 2be361fbb9 (closes issue #6002)
Reported by: rizzo
Tested by: murf

Proposal of the changes to be made, and then an announcement of how they were accomplished:

http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html

and:

http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html

Here is a recap, file by file, of what I have done:

pbx/pbx_config.c
pbx/pbx_ael.c

All funcs that were passed a ptr to the context list, now will ALSO be passed a hashtab ptr to the same set.
Why? because (for the time being), the dialplan is stored in both, to facilitate a quick, low-cost move to
hash-tables to speed up dialplan processing. If it was deemed necessary to pass the context LIST, well, it
is just as necessary to have the TABLE available. This is because the list/table in question might not be
the global one, but temporary ones we would use to stage the dialplan on, and then swap into the global
position when things are ready.

We now have one external function for apps to use, "ast_context_find_or_create()" instead of the pre-existing
"find" and "create", as all existing usages used both in tandem anyway.

pbx_config, and pbx_ael, will stage the reloaded dialplan into local lists and tables, and 
then call merge_contexts_and_delete, which will merge (now) existing contexts and 
priorities from other registrars into this local set by copying them. Then, merge_contexts_and_delete will
lock down the contexts, swap the lists and tables, and unlock (real quick), and then 
destroy the old dialplan.



chan_sip.c
chan_iax.c
chan_skinny.c

All the channel drivers that would add regcontexts now use the ast_context_find_or_create now.

chan_sip also includes a small fix to get rid of warnings about removing priorities that never got entered.


apps/app_meetme.c
apps/app_dial.c
apps/app_queue.c

All the apps that added a context/exten/priority were also modified to use ast_context_find_or_create instead.


include/asterisk/pbx.h

ast_context_create() is removed. Find_or_create_ is the new method.
ast_context_find_or_create()  interface gets the hashtab added.
ast_merge_contexts_and_delete() gets the local hashtab arg added.
ast_wrlock_contexts_version() is added so you can detect if someone else got a writelock between your readlocking and writelocking.
ast_hashtab_compare_contexts was made public for use in pbx_config/pbx_ael
ast_hashtab_hash_contexts was in like fashion make public.


include/asterisk/pval.h

ast_compile_ael2() interface changed to include the local hashtab table ptr.


main/features.c

For the sake of the parking context, we use ast_context_find_or_create().



main/pbx.c

I changed all the "tree" names to "table" instead. That's because the original
implementation was based on binary trees. (had a free library). Then I moved
to hashtabs. Now, the names move forward too.

refcount field added to contexts, so you can keep track of how many modules
wanted this context to exist.

Some log messages that are warnings were inflated from LOG_NOTICE to LOG_WARNING.

Added some calls to ast_verb(3,...) for debug messages

Lots of little mods to ast_context_remove_extension2, which is now excersized in ways
it was not previously; one definite bug fixed.

find_or_create was upgraded to handle both local lists/tables as well as the globals.

context_merge() was added to do the per-context merging of the old/present contexts/extens/prios into the new/proposed local list/tables

ast_merge_contexts_and_delete() was heavily modified.

ast_add_extension2() was also upgraded to handle changes. 

the context_destroy() code was re-engineered to handle the new way of doing things,
by exten/prio instead of by context.



res/ael/pval.c
res/ael/ael.tab.c
res/ael/ael.tab.h
res/ael/ael.y
res/ael/ael_lex.c
res/ael/ael.flex
utils/ael_main.c
utils/extconf.c
utils/conf2ael.c
utils/Makefile

Had to change the interface to ast_compile_ael2(), to include the hashtab ptr.
This ended up involving several external apps.  The main gotcha was I had to 
include lock.h and hashtab.h in several places.


As a side note, I tested this stuff pretty thoroughly, I replicated the problems
originally reported by Luigi, and made triply sure that reloads worked, and everything
worked thru "stop gracefully". I found a and fixed a few bugs as I was merging into
trunk, that did not appear in my tests of bug6002.

How's this for verbose commit messages?




git-svn-id: http://svn.digium.com/svn/asterisk/trunk@106757 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07 18:57:57 +00:00
murf 0eb21c8f2d Merged revisions 97889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r97889 | murf | 2008-01-10 14:37:10 -0700 (Thu, 10 Jan 2008) | 1 line

Applied the same fixes for ael.flex as was done in 97849 for ast_expr2.fl; overrode the normally generate yyfree func with our own version that checks the pointer for non-null before passing to free(). Also takes care of a little problem with 2.5.33 and the use of the __STDC_VERSION__ macro.
........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@97890 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-10 21:46:56 +00:00
murf 0c96bd8c5f made AEL 8-bit transparent; mainly the lexer was tossing chars with the hi-order bit set. Not nice. Also, allow @ in extension names, and a backslash, also.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@89682 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-27 18:50:44 +00:00
murf 15b76d347e Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line

closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@87187 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-26 17:39:39 +00:00
murf f7ffafc70a closes issue #11005, where #include uses the current dir instead of the config dir (/etc/asterisk) for relative path includes for AEL
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@86967 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-24 13:21:29 +00:00
murf a183e3c165 Merged revisions 84133 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r84133 | murf | 2007-09-29 15:47:53 -0600 (Sat, 29 Sep 2007) | 1 line

This issue sort of closes 10786; All config files support #include with globbing (you know, *,[chars],?,{list,list},etc), so I've updated the AEL system to support this also.
........


git-svn-id: http://svn.digium.com/svn/asterisk/trunk@84137 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-29 23:47:59 +00:00
murf e897b4499e This commit closes bug 7605, and half-closes 7638. The AEL code has been redistributed/repartitioned to allow code re-use both inside and outside of Asterisk. This commit introduces the utils/conf2ael program, and an external config-file reader, for both normal config files, and for extensions.conf (context, exten, prio); It provides an API for programs outside of asterisk to use to play with the dialplan and config files.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@79595 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-15 19:21:27 +00:00