ast_pbx_outgoing_app is called. The reason is that __ast_request_and_dial
allocates the cdr for the channel, so it should be expected that the channel
will have a cdr on it.
Thanks to joetester on IRC for pointing this out
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@106437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
len field in an ast_frame of audio was wrong when G.722 is in use. The len field
represents the number of ms of audio that the frame contains. It would have
set the value to be twice what it should be.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@105563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the list of channels in autoservice. The problem was that it was possible for
a channel to get removed from autoservice and destroyed, while the autoservice
thread was still messing with the channel. This led to memory corruption, and
caused crashes. This explains multiple backtraces I have seen that have
references to autoservice, but do to the nature of the issue (memory corruption),
could cause crashes in a number of areas.
(fixes the crash in BE-386)
(closes issue #11694)
(closes issue #11940)
The following issues could be related. If you are the reporter of one of these,
please update to include this fix and try again.
(potentially fixes issue #11189)
(potentially fixes issue #12107)
(potentially fixes issue #11573)
(potentially fixes issue #12008)
(potentially fixes issue #11189)
(potentially fixes issue #11993)
(potentially fixes issue #11791)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@105409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@105116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@105005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
