https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105116 | russell | 2008-02-28 16:23:05 -0600 (Thu, 28 Feb 2008) | 8 lines
Fix a bug in the lock tracking code that was discovered by mmichelson. The issue
is that if the lock history array was full, then the functions to mark a lock as
acquired or not would adjust the stats for whatever lock is at the end of the array,
which may not be itself. So, do a sanity check to make sure that we're updating
lock info for the proper lock.
(This explains the bizarre stats on lock #63 in BE-396, thanks Mark!)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105059 | mmichelson | 2008-02-28 14:11:57 -0600 (Thu, 28 Feb 2008) | 6 lines
When using autofill, members who are in use should be counted towards the
number of available members to call if ringinuse is set to yes.
Thanks to jmls who brought this issue up on IRC
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104841 | mmichelson | 2008-02-27 15:49:20 -0600 (Wed, 27 Feb 2008) | 17 lines
Two fixes:
1. Make the list of ast_dial_channels a lockable list. This is because in some cases,
the ast_dial may exist in multiple threads due to asynchronous execution of its application, and
I found some cases where race conditions could exist.
2. Check in ast_dial_join to be sure that the channel still exists before attempting to lock it, since
it could have gotten hung up but the is_running_app flag on the ast_dial_channel may not have been
cleared yet.
(closes issue #12038)
Reported by: jvandal
Patches:
12038v2.patch uploaded by putnopvut (license 60)
Tested by: jvandal
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105005 | qwell | 2008-02-28 13:20:10 -0600 (Thu, 28 Feb 2008) | 9 lines
Make pbx_exec pass an empty string into applications, if we get NULL.
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: https://origsvn.digium.com/svn/asterisk/trunk@105006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104593 | kpfleming | 2008-02-27 10:53:06 -0600 (Wed, 27 Feb 2008) | 8 lines
fallback to standard English prompts properly when using new prompt directory layout
(closes issue #11831)
Reported by: IgorG
Patches:
fallbacken.v1.diff uploaded by IgorG (license 20) (modified by me to improve code and conform rest of function to coding guidelines)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r104591 | russell | 2008-02-27 10:45:00 -0600 (Wed, 27 Feb 2008) | 4 lines
When we receive a known alarm, make sure that the unknown alarm flag is not still
set to make sure that when we come back out of alarm, it gets reported in the log
and manager interface (after discussion with tzafrir on the -dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that if we keep this in the tree, it will be much easier to keep up to date.
The page on asterisk.org just links to this on svn.digium.com/view
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104419 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r104332 | russell | 2008-02-26 18:54:29 -0600 (Tue, 26 Feb 2008) | 5 lines
Zaptel 1.4 now exposes FXO battery state as an alarm. However, Asterisk 1.4
does not know what to do with these alarms. Only Asterisk 1.6 cares about it.
So, if we get an unknown alarm in chan_zap, don't generate confusing log messages
about it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
automatically generated file like it used to be. This still needs to be there
for modules that have to check it to compile against multiple asterisk versions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r104132 | qwell | 2008-02-26 10:08:44 -0600 (Tue, 26 Feb 2008) | 9 lines
Fix a very bizarre issue we were seeing with our buildbot when using a DESTDIR that
wasn't an absolute path (such as DESTDIR=~/asterisk-1.4).
Apparently what was happening, was that some of the targets were being expanded to
the full path, so $@ ended up being /root/asterisk-1.4/[...]/ rather than ~/asterisk-1.4/[...]/
It appears that this may be a new "feature" in GNU make.
(*cough* http://en.wikipedia.org/wiki/Principle_of_least_surprise *cough*)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua Colp
Philippe Sultan
Tilghman Lesher
Russell Bryant
Mark Michelson
Jason Parker
Kevin P. Fleming
Steve Murphy
Olle Johansson