peers. Instead, use an iterator. By using an iterator, the peers container
is not locked while the POKE is being done. It can cause a deadlock if the
peers container is locked because poking a peer will try to lock pvt structs,
while there is a lot of other code that will hold a pvt lock when trying to
go lock the peers container.
(reported to me directly by Loic Didelot. Thank you for the debug info!)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@83175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: jamesgolovich
Patches:
asterisk-iaxfirmwareleak.diff.txt uploaded by jamesgolovich (license 176)
Fix memory leak when unloading chan_iax2. The firmware files were not being freed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
handling blocks in the code for building peers. The peer object destructor
does this and doing it twice will cause a crash.
(closes issue #10625, reported by and patched by pnlarsson)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
places that scheduled items to be executed by the scheduler thread did not
signal the scheduler thread to wake up so that it could recalculate the time
until the next action. These changes will make the scheduler thread more
responsive and ensure that actions get executed as close to when intended as
possible instead of it being possible for very long delays.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
starts, then don't give up on poking peers. Allow the poke to get rescheduled
so that it will work once the dnsmgr is able to resolve the host.
(closes issue #10521, patch by jamesgolovich)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the peers and users are being stored in a linked list, that they go in the
list in the same order that the older code used. This is necessary to maintain
the behavior of which peers and users get matched when traversing the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects. It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them. The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.
To accomplish this, I used the astobj2 reference counted object model. This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone. I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.
As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating. Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.
The use of the hash table will be made the default in trunk. It is not the default
in 1.4 because it changes the behavior slightly. Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration. The hash table does not guarantee any order in the container,
so this behavior will be going away. It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.
If you have any questions, feel free to ask on the asterisk-dev list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and scheduling multi-threaded. Unfortunately, we have to do some expensive
deadlock avoidance when queueing frames on to the ast_channel owner of the IAX2
pvt struct. This was already handled for regular frames, but ast_queue_hangup
and ast_queue_control were still used directly. Making these changes introduced
even more places where the IAX2 pvt struct can disappear in the context of a
function holding its lock due to calling a function that has to unlock/lock it
to avoid deadlocks. I went through and fixed all of these places to account for
this possibility.
(issue #10362, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
core issue. You can not call find_callno() while holding a pvt lock as this
function has to lock another (every) other pvt lock. Doing so can lead to a
classic deadlock. So, I am tracking down all of the code paths where this
can happen and fixing them.
The fix I committed earlier today was along the same theme. This patch fixes
some code down the path of authenticate_reply.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
call find_callno. You can't hold a pvt lock while calling find_callno because
it goes through and locks every single one looking for a match.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: haklin
Don't set the callerid name and number a second time on a newly created channel. ast_channel_alloc itself already sets it and setting it twice would cause a memory leak.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
will just return immediately. Also, fix some logic so the thread's lock
isn't unlocked twice in the weird case of dynamic threads getting acquired
right after a timeout.
(pointed out by SteveK)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
during the first time it runs. This shouldn't ever happen, but we should
account for it anyway.
(pointed out by pete, who works with mihai)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
thread timed out waiting for something to do, but was acquired to perform an
action immediately afterwords, then wait on the condition again to give the
other thread a chance to finish setting up the data for what action this thread
should perform. Otherwise, if it immediately continues, it will perform the
wrong action.
(reported on IRC by mihai, patch by me)
(related to issue #10289)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The most notable problem is that people have been seeing storms of VNAK frames
being sent due to really old frames mysteriously being in the retransmission
queue and never getting removed.
It was possible that a dynamic thread got created, but did not acquire its lock
before the thread that created it signals it to perform an action. When this
happens, the thread will sleep until it hits a timeout, and then get destroyed.
So, the action never gets performed and in some cases, means a frame doesn't
get transmitted and never gets freed since the scheduler never gets a chance
to reschedule transmission.
Another less severe race condition is in the handling of a timeout for a dynamic
thread. It was possible for it to be acquired to perform at action at the same
time that it hit a timeout. When this occurs, whatever action it was acquired
for would never get performed.
(patch contributed by Mihai and SteveK)
(closes issue #10289)
(closes issue #10248)
(closes issue #10232)
(possibly related to issue #10359)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queue. In the network_thread() loop, it traverses the list using the
AST_LIST_TRAVERSE_SAFE macro. However, to remove an element of the list within
this loop, it used AST_LIST_REMOVE, instead of AST_LIST_REMOVE_CURRENT, which I
believe could leave some of the internal variables of the SAFE macro invalid.
Mihai says that he already made this change in his local copy and it didn't help
his VNAK storm issues, but I still think it's wrong. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the network. Using an unsigned value here made it impossible to handle an
error returned from recvfrom(). Furthermore, in the case that recvfrom()
did return an error, this would cause a crash due to a heap overflow.
(closes issue #10265, reported by and fix suggested by timrobbins)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75927 | russell | 2007-07-19 10:49:42 -0500 (Thu, 19 Jul 2007) | 6 lines
When processing full frames, take sequence number wraparound into account when
deciding whether or not we need to request retransmissions by sending a VNAK.
This code could cause VNAKs to be sent erroneously in some cases, and to not
be sent in other cases when it should have been.
(closes issue #10237, reported and patched by mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75757 | russell | 2007-07-18 16:09:13 -0500 (Wed, 18 Jul 2007) | 5 lines
When traversing the queue of frames for possible retransmission after
receiving a VNAK, handle sequence number wraparound so that all frames that
should be retransmitted actually do get retransmitted.
(issue #10227, reported and patched by mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75444 | russell | 2007-07-17 15:45:27 -0500 (Tue, 17 Jul 2007) | 5 lines
Ensure that when encoding the contents of an ast_frame into an iax_frame, that
the size of the destination buffer is known in the iax_frame so that code
won't write past the end of the allocated buffer when sending outgoing frames.
(ASA-2007-014)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@75445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r74766 | russell | 2007-07-11 17:53:26 -0500 (Wed, 11 Jul 2007) | 5 lines
The function make_trunk() can fail and return -1 instead of a valid new call
number. Fix the uses of this function to handle this instead of treating it
as the new call number. This would cause a deadlock and memory corruption.
(possible cause of issue #9614 and others, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
set to ease debugging
* When deferring a full frame for processing, stick it into the queue for the
thread that is processing frames for that call, not the one that read the
current frame and is about to go back into the idle list
(related to issue #9937)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@73551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of handling a full frame for the same call, queue it up for processing by that
same thread later instead of dropping it.
(issue #9937, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@70866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
