After debugging a deadlock, it was noticed that when DEBUG_CHANNEL_LOCKS
is enabled in menuselect, the actual origin of channel locks is obscured
by the fact that all channel locks appear to happen in the function
ast_channel_lock(). This code change redefines ast_channel_lock to be a
macro which maps to __ast_channel_lock(), which then relays the proper
file name, line number, and function name information to the core lock
functions so that this information will be displayed in the case that
there is some sort of locking error or core show locks is issued.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@116088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in ast_autoservice_stop().
The reason these threads were waiting around is because this function waits to
ensure that the channel list in the autoservice thread gets rebuilt before the
stop() function returns. However, the autoservice thread was also locked, so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local channel.
However, the local channel was locked by a thread that was stuck in the autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function in
chan_local. This function assumed that one of the channels passed in as an
argument was locked when called. However, that was not always the case. There
were multiple cases in which this channel was not locked when the function was
called. We fixed up chan_local to indicate to this function whether this channel
was locked or not. The previous assumption had caused local_queue_frame() to
improperly return with the channel locked, where it would then never get unlocked.
(closes issue #12584)
(related to issue #12603)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@116038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a different problem. I noticed that it was theoretically possible for two threads
to attempt to start the autoservice thread at the same time. This change makes the
process of starting the autoservice thread, thread-safe.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a core show locks command. This will help to de-clutter output somewhat.
Russell said it would be fine to place this improvement in the 1.4 branch, so that's
why it's going here too.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines
Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy. We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.
It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed. So, that frame did not include
the destination call number, because it didn't have it yet. Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one. This
caused the frame to be rejected with an INVAL. The frame would get retransmitted
for forever, rejected every time ...
This race condition exists in all versions that got the security changes,
in theory. However, it is really only likely that this would cause a problem in
Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing
all versions that could potentially be affected by the introduced race condition.
These changes are what bbryant and I came up with to fix the issue. Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly. If it doesn't complete after yielding for a little
while, then the frame gets dropped.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a queue member. There was too much of an opportunity for the member
to hang up (either during a delay, announcement, or overly long
agi) between the time that he answered the phone and the time when
he actually was bridged with the caller. The consequence of this
was that if the member hung up in that interval, then proper
abandonment details would not be noted in the queue log if the caller
were to hang up at any point after the member hangup.
(closes issue #12561)
Reported by: ablackthorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It fixes authentication with Primus in Canada, and has been in use for a very long
time without causing problems with any other providers.
(closes issue AST-36)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
