- the output of flex includes a static function called 'input' that is not used, so for the moment we'll stop having the compiler tell us about unused variables in the flex source files (a better fix would be to improve our flex post-processing to remove the unused function)
- main/stdtime/localtime.c makes assumptions about signed integer overflow, and gcc-4.3's improved optimizer tries to take advantage of handling potential overflow conditions at compile time; for now, suppress these optimizations until we can fiure out if the code needs improvement
- main/udptl.c has some references to uninitialized variables; in one case there was no bug, but in the other it was certainly possibly for unexpected behavior to occur
- main/editline/readline.c had an unused variable
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@107352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PBX is started on the channel using ast_pbx_start(), then the ownership of the
channel has been passed on to another thread. We can no longer access it in this
code. If the channel gets hung up very quickly, it is possible that we could
access a channel that has been free'd.
(inspired by BE-386)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@107161 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on the channel (such as if you set a call limit based on the system's load
average), then there were cases where a channel that has already been free'd
using ast_hangup() got accessed. This caused weird memory corruption and
crashes to occur.
(fixes issue BE-386)
(much debugging credit goes to twilson, final patch written by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@107158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and it is not worth spamming users with these messages unless we are pretty confident
that it should never happen. As it stands today, it _will_ and _does_ happen and
until that gets cleaned up a reasonable amount on the development side, let's not
spam the logs of everyone else.
(closes issue #12154)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@106704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
