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/branches/1.4@104841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(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/branches/1.4@104593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
failed to lock don't sit around in the history. When a lock is first locked,
this checks to see if the last lock in the list was one that was failed to be
locked. If it is, then that was a lock that we're no longer sitting in a trylock
loop trying to lock, so just remove it.
(inspired by issue #11712)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, this fixes using #include and #exec in extconfig.conf.
This was basically caused because the config file itself raises the include level to 1.
I opted not to raise the include limit, because recursion here could cause very bizarre behavior.
Pointed out, and tested by jmls
(closes issue #12064)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was created properly. Unfortunately this led to a segfault in the situation where an unknown format was
specified in voicemail.conf and a voicemail was recorded. Now, we first check to be sure that the stream
was written correctly or else assume a zero duration.
(closes issue #12021)
Reported by: jakep
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST_MODULE_LOAD_DECLINE, log a message indicating that the module is not fully
initialized and must be initialized using "module load".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from a translator. This showed itself by g729 decoders not getting released.
Since the flag inside the translator frame never got unset by freeing the frame
to indicate it was no longer in use, the translators never got destroyed, and
thus the g729 licenses were not released.
(closes issue #11892)
Reported by: xrg
Patches:
11892.diff uploaded by russell (license 2)
Tested by: xrg, russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@100581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@100465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@99081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@99004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@98943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Normally, we would not backport features into 1.4, but, I was convinced by the
justification supplied by the supplier of this patch. He pointed out that this
patch removes a requirement for running as root, thus reducing the potential
impacts of security issues.
(closes issue #11742)
Reported by: paravoid
Patches:
libcap.diff uploaded by paravoid (license 200)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
