| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242969 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242852 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242728 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242723 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
detected by the configure script.
Changed after discussion on the -dev list about possible unnecessary build
failures, due to checkouts/untars causing these special source files to
possibly be newer than their resulting C files. This should additionally
ensure that nobody need learn about extra Makefile arguments to ensure the
proper files get rebuilt when changes are made to these special source files.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242520 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #14629)
Reported by: Marquis
Patches:
20100121__issue14629.diff.txt uploaded by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@242423 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I should have taken a closer look at trunk/1.6.x, as this bug has already been
fixed in a much more simple manner, by just settings o->vars to NULL after the
ast_pbx_outgoing_* calls.
(issue #16554)
Reported by: mav3rick
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@241544 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In pbx_spool, when we are freeing our 'outgoing' struct, we weren't deallocating
the ast_variable list we had built from SetVars in a call file. Adding a call to
ast_variables_destroy in our deallocation routine works, but only if the variables
have not already been passed into ast_pbx_outgoing_app() or _exten(), both of
which take care of destroying the variable list for us.
(closes issue #16554)
Reported by: mav3rick
Patches:
issue16554_20100119.patch uploaded by seanbright (license 71)
Tested by: mav3rick
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@241543 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Parse global variables or expressions in hint extensions. Like: exten => 400,hint,DAHDI/i2/${GLOBAL(var)}
(closes issue #16166)
Reported by: rmudgett
Tested by: mnick, rmudgett
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@233091 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit changes the build system so that user-provided flags (in ASTCFLAGS
and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided
by the build system itself, so that the user can effectively override the
build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now
be provided *either* in the environment before running 'make', or as variable
assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS
is no longer necessary, so they are no longer documented, but are still supported
so as not to break existing build systems that supply them when building Asterisk.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207647 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
We were trying to reference members of a struct that had previously been freed.
This patch makes sure that we free the struct after it has been removed from
the spooler queue.
(closes issue #15072)
Reported by: garlew
Patches:
spool.diff uploaded by garlew (license 376)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@198957 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch simply removes some old code back before Asterisk used editline.
This fixes the crash that occurred when tab-completing "remove extension".
(closes issue #14689)
Reported by: isaacgal
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191096 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
AEL was not handling the case of a device hint containing an @ symbol, which
caused parking hints (e.g. hint(park:exten@context)) to error out the parser.
This patch makes AEL treat the @ the same way it treats colon and ampersand
now, meaning the characters are included in verbatim.
(closes issue #14941)
Reported by: bpgoldsb
Patches:
bug14941.patch uploaded by seanbright (license 71)
Tested by: bpgoldsb
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189462 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue. Because using the ast prefix calls are
a better choice, ast_free_ptr is the new wrapper for free to pass to functions.
Also, a little bit of clean up was done to avoid the debug macros intentionally
being redefined.
(closes issue #13593)
Reported by: pj
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@181133 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
rev 24425.
It basically fixes AST-190/ABE-1782.
What was wrong: the user has 6000 extensions in one context; and
then 6000 contexts, one per extension. The parser could only handle
about 4893 of the 6000 extens in the single context.
This was due to the regression I mentioned. To get rid of
shift/reduce conflicts, Luigi set up right-recursive lists
for globals, context elements, switch lists, and statements.
Right recursive lists got rid of the warnings, but instead, they
use up a tremendous amount of stack space when the lists are long.
I saw this a few years back, and resolved not to fix it until
someone complained. That day has arrived!
After the changes were made, I ran the regression test suite,
and there were no problems.
I took the test case the user provided, and added 100,000
extensions to the single context, that already had 6,000 extens
in it. (I'll see your 6, and raise you 100!) It takes a few minutes
to read it all in, check it and generate code for it, but no
problems.
So, I think I can say that fundamentally, there are no longer
any limits on the number of items you can place in contexts,
statement blocks, switches, or globals, beyond your virt mem
constraints.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177225 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14263)
Reported by: markd
Patches:
20090120__bug14263.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170158 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
fails a consistency check because it can't find a matching
extension. The problem was a missing instruction to end
the range notation in the code where it converts the pattern
into a regex and uses the regex code to determine the match.
I tested using the AEL code the user supplied, and now,
the consistency check passes.
(closes issue #14141)
Reported by: dimas
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168745 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
on 64-bit machines, as well.
(inspired by issue #13879)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163511 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13819)
Reported by: adomjan
Patches:
pbx_dundi.c-clearcache.patch uploaded by adomjan (license 487)
dundi_clearecache3.diff uploaded by mnicholson (license 96)
Tested by: adomjan
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163316 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: wetwired
Tested by: murf
I checked, and I added a mod to the trunk version
of Asterisk that would make it 8-bit transparent
on 27 Nov 2007, but I made no such updates to
1.4. My best guess is that 1.4 was released, and
it was not appropriate to commit an enhancement.
But I'm going to add the same fixes to 1.4 now,
for the following reasons:
1. wetwired is correct; 1.4 is **mostly** 8-bit
transparent now. This is because the lexical
token forming rules use . in most 'word'
state continuances. It's just the beginning
of a 'word' that is picky.
2. Accepting 8-bit chars in some places and
not others leads to bug reports like this.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162671 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@162264 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
standalone stuff. Fixed.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162136 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@162013 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
then that new entry will not be processed promptly, but must wait for either a
future entry to start or a current entry's retry to occur. If no other entries
exist in the directory (other than the new entries) when a bunch expire, then
the new entries must wait until another new entry is added to be processed.
This was a rather weird race condition, really. Fixes AST-147.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160558 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
required modules (channels, apps, functions) may not yet be in memory yet.
Fixes AST-149.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160551 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
variables, unreachable code, etc.), which is good. however, developers usually compile with the optimizer turned off, because if they need to debug the resulting code, optimized code makes that process very difficult. this means that we get code changes committed that weren't adequately checked over for these sorts of problems.
with this build system change, if (and only if) --enable-dev-mode was used and DONT_OPTIMIZE is turned on, when a source file is compiled it will actually be preprocessed (into a .i or .ii file), then compiled once with optimization (with the result sent to /dev/null) and again without optimization (but only if the first compile succeeded, of course).
while making these changes, i did some cleanup work in Makefile.rules to move commonly-used combinations of flag variables into their own variables, to make the file easier to read and maintain
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@157859 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153823 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
being passed to printf()-like functions and ignored results from read()/write() and friends
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@153337 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- it is no longer necessary to forcibly include asterisk/autoconfig.h; every module already includes asterisk.h as its first header (even before system headers), which serves the same purpose
- astmm.h is now included by asterisk.h when needed, instead of being forced by the Makefile; this means external modules will build properly against installed headers with MALLOC_DEBUG enabled
- simplify the usage of some of these headers in the AEL-related stuff in the utils directory
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@144924 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(issue #13332)
Reported by: wizzy
Tested by: bkruse
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@143612 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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/branches/1.4@141094 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: korihor
Wow, this one was a challenge!
I regrouped and ran a new strategy for
setting the ~~MACRO~~ value; I set it once
per extension, up near the top. It is only
set if there is a switch in the extension.
So, I had to put in a chunk of code to detect
a switch in the pval tree.
I moved the code to insert the set of ~~exten~~
up to the beginning of the gen_prios routine,
instead of down in the switch code.
I learned that I have to push the detection
of the switches down into the code, so everywhere
I create a new exten in gen_prios, I make sure
to pass onto it the values of the mother_exten
first, and the exten next.
I had to add a couple fields to the exten
struct to accomplish this, in the ael_structs.h
file. The checked field makes it so we don't
repeat the switch search if it's been done.
I also updated the regressions.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136726 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
from callfiles and AMI.
(closes issue #9531)
Reported by: Geisj
Patches:
20080715__bug9531__1.4.diff.txt uploaded by Corydon76 (license 14)
20080715__bug9531__1.6.0.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134976 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: pj
(closes issue #13051)
Reported by: pj
This patch substitutes commas in the expr
supplied to the if () statement, as in
if ( expr ) ...
This solves both the bugs above, and makes
the source symmetric with switch statements,
which were earlier reported to need this sort
of treatment.
I tested this using the examples, both for
the compiler and at run time. Looks good.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134652 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
compiled with LOW_MEMORY.
(closes issue #13154)
Reported by: edantie
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134595 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: murf
The problem was that, esoteric as it is, because the hangerupper
context immediately preceded the std-priv-extent macro, that
the checking code accidentally would fall from traversing hangerupper
into the std-priv-exten macro, where it would hit the hangerupper
in the 'includes', and proceed into an infinite recursion.
A small fix to traverse into the statements of the context instead
of the context solves this issue.
I also added some commented out printfs for debug, which were pretty
handy in the face of a dorky gdb.
This was a problem around since the package was first written;
but evidently pretty rare in turning up in the field.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131242 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit fixes the use of RAND in the ael random function.
(closes issue #13061)
Reported by: danpwi
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130373 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@128029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
and b) completes contexts correctly when the extension is ambiguous.
(closes issue #12980)
Reported by: licedey
Patches:
20080703__bug12980.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127973 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@126395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the last one will take precedence.
(closes issue #12673)
Reported by: phber
Patches:
20080519__bug12673.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@123710 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
should continue working. Release announcement to follow.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
some formatting, and make the success message a little bit more clear.
(closes AST-52)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120371 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(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
|
|
cannot perform any translation on the extension number before searching for it
in the target context.
(closes issue #12473)
Reported by: chappell
Patches:
pbx_loopback.c.diff uploaded by chappell (license 8)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120226 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
this for the changes I made to preserve ${EXTEN}
in switches, which affected several tests because
it adds extra priorities, and at least one needed to be updated
because of the removal of the empty extension warning
message.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119966 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
which is a message from Philipp Kempgen, requesting that the WARNING
that an extension is empty be reduced to a NOTICE or less, as empty
extensions are syntactically possible, and no big deal.
With which I agree, and have removed that WARNING message entirely.
I think it is not necessary to see this message. It didn't
state that a NoOp() was inserted automatically on your behalf,
and really, as users, who cares? Why freak out dialplan writers
with unnecessary warnings? The details of the machinations a compiler goes
thru to produce working assembly code is of little interest
to most programmers-- we will follow the unix principal of
doing our work silently.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119929 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117523 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #12702)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@117519 f38db490-d61c-443f-a65b-d21fe96a405b
|
