LIST instead of an RWLIST. The way this list works makes it such that
a RWLIST provides no additional benefit. Also, a mutex is needed for
use with the thread condition.
Merged revisions 105563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r105563 | russell | 2008-03-03 09:50:43 -0600 (Mon, 03 Mar 2008) | 24 lines
Merge in some changes from team/russell/autoservice-nochans-1.4
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@105564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
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
........
r104119 | russell | 2008-02-25 18:25:29 -0600 (Mon, 25 Feb 2008) | 33 lines
Merge changes from team/russell/smdi-1.4
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@104120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1024 was used instead of 128 when using AES from OpenSSL. Many thanks
to d1mas for figuring this one out!
(closes issue #11946)
Reported by: bbhoss
Patches:
v1-11946.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also removes second check for awk, which causes Solaris to find an incompatible version of awk.
(closes issue #11829)
Reported by: snuffy
Patches:
bug-11829.diff uploaded by snuffy (license 35)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to retrieve list of categories in a config file.
Added ability to retrieve the content of a particular category.
Added ability to empty a context.
Created new action to create a new file.
Updated delete action to allow deletion by line number with respect to category.
Added new action insert to add new variable to category at specified line.
Updated action newcat to allow new category to be inserted in file above another existing category.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@103331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100581 | russell | 2008-01-28 11:15:41 -0600 (Mon, 28 Jan 2008) | 9 lines
Make some deadlock related fixes. These bugs were discovered and reported
internally at Digium by Steve Pitts.
- Fix up chan_local to ensure that the channel lock is held before the local
pvt lock.
- Don't hold the channel lock when executing the timing function, as it can
cause a deadlock when using chan_local. This actually changes the code back
to be how it was before the change for issue #10765. But, I added some other
locking that I think will prevent the problem reported there, as well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
that was just merged from 1.4, so this is a changeover to those APIs to use the
macro versions, so that we properly detect errors from ast_sched_del, instead
of simply ignoring the return values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100465 | tilghman | 2008-01-27 15:59:53 -0600 (Sun, 27 Jan 2008) | 11 lines
When deleting a task from the scheduler, ignoring the return value could
possibly cause memory to be accessed after it is freed, which causes all
sorts of random memory corruption. Instead, if a deletion fails, wait a
bit and try again (noting that another thread could change our taskid
value).
(closes issue #11386)
Reported by: flujan
Patches:
20080124__bug11386.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, flujan, stuarth`
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r100264 | kpfleming | 2008-01-24 15:57:41 -0600 (Thu, 24 Jan 2008) | 2 lines
make these macros not assume that the only other field in the structure is 'argc'... this is true when someone uses AST_DECLARE_APP_ARGS, but it's perfectly reasonable to define your own structure as long as it has the right fields
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@100265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
as a channel variable BRIDGEPVTCALLID
This is important for call tracing in log files and CDRs, so that
the SIP callID can be traced along servers.
The CHANNEL dialplan function won't work here, since the outbound
channel is gone when we need the Call-ID.
Other channel drivers may now implement the same function :-),
but this patch only supports chan_sip.so.
Inspired by (issue #11816)
Reported by: ctooley
Patch by oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99341 | tilghman | 2008-01-21 12:11:07 -0600 (Mon, 21 Jan 2008) | 8 lines
Permit the user to specify number of seconds that a connection may remain idle,
which fixes a crash on reconnect with the MyODBC driver.
(closes issue #11798)
Reported by: Corydon76
Patches:
20080119__res_odbc__idlecheck.diff.txt uploaded by Corydon76 (license 14)
Tested by: mvanbaak
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes introduces TCP and TLS support for chan_sip. There are various
new options in configs/sip.conf.sample that are used to enable these features. Also,
there is a document, doc/siptls.txt that describes some things in more detail.
This code was implemented by Brett Bryant and James Golovich. It was reviewed
by Joshua Colp and myself. A number of other people participated in the testing
of this code, but since it was done outside of the bug tracker, I do not have their
names. If you were one of them, thanks a lot for the help!
(closes issue #4903, but with completely different code that what exists there.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99085 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99081 | russell | 2008-01-18 15:37:21 -0600 (Fri, 18 Jan 2008) | 9 lines
Revert adding the packed attribute, as it really doesn't make sense why that
would do any good. Fix the real bug, which is to do the check to see if the
frame came from a translator at the beginning of ast_frame_free(), instead of
at the end. This ensures that it always gets checked, even if none of the
parts of the frame are malloc'd, and also ensures that we aren't looking at
free'd memory in the case that it is a malloc'd frame.
(closes issue #11792, reported by explidous, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99079 | russell | 2008-01-18 15:22:21 -0600 (Fri, 18 Jan 2008) | 4 lines
Since we're relying on the offset between the frame and the beginning of the translator
pvt struct, set the packed attribute to make sure we get to the right place.
(potential fix for issue #11792)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r99004 | russell | 2008-01-17 16:37:22 -0600 (Thu, 17 Jan 2008) | 10 lines
Have IAX2 optimize the codec translation path just like chan_sip does it. If
the caller's codec is in our codec list, move it to the top to avoid transcoding.
(closes issue #10500)
Reported by: stevedavies
Patches:
iax-prefer-current-codec.patch uploaded by stevedavies (license 184)
iax-prefer-current-codec.1.4.patch uploaded by stevedavies (license 184)
Tested by: stevedavies, pj, sheldonh
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@99006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r98943 | russell | 2008-01-15 17:26:52 -0600 (Tue, 15 Jan 2008) | 25 lines
Commit a fix for some memory access errors pointed out by the valgrind2.txt
output on issue #11698.
The issue here is that it is possible for an instance of a translator to get
destroyed while the frame allocated as a part of the translator is still being
processed. Specifically, this is possible anywhere between a call to ast_read()
and ast_frame_free(), which is _a lot_ of places in the code. The reason this
happens is that the channel might get masqueraded during this time. During a
masquerade, existing translation paths get destroyed.
So, this patch fixes the issue in an API and ABI compatible way. (This one is
for you, paravoid!)
It changes an int in ast_frame to be used as flag bits. The 1 bit is still used
to indicate that the frame contains timing information. Also, a second flag has
been added to indicate that the frame came from a translator. When a frame with
this flag gets released and has this flag, a function is called in translate.c to
let it know that this frame is doing being processed. At this point, the flag gets
cleared. Also, if the translator was requested to be destroyed while its internal
frame still had this flag set, its destruction has been deffered until it finds out
that the frame is no longer being processed.
Admittedly, this feels like a hack. But, it does fix the issue, and I was not able
to think of a better solution ...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@98944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
