Age | Commit message (Collapse) | Author | Files | Lines |
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.20-rc3@116244 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.20-rc3@116243 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/tags/1.4.20-rc3@116242 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Content-Type: text/plain;charset=Södermanländska
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116230 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
defined.
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: http://svn.digium.com/svn/asterisk/branches/1.4@116088 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@116038 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@115990 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12616)
Reported by: nicklewisdigiumuser
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115944 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #12637)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115884 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
issuing
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: http://svn.digium.com/svn/asterisk/branches/1.4@115735 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115579 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115568 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@115565 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Timeout.
(closes issue #12323)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115561 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #9676)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115557 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12611)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115554 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12609)
Reported by: edantie
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115551 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12611)
Reported by: b_plessis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115545 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a qualify ping or a subscription. This fixes some realtime related crashes.
(closes issue #12588)
(closes issue #12555)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115517 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115511 | russell | 2008-05-07 11:22:49 -0500 (Wed, 07 May 2008) | 3 lines
Remove remnants of dlinkedlists. I didn't actually use them in the final version
of my IAX2 improvements.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115512 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115421 | qwell | 2008-05-06 14:54:57 -0500 (Tue, 06 May 2008) | 7 lines
read requires an argument on some non-bash shells
(closes issue #12593)
Reported by: bkruse
Patches:
getilbc.sh_12593_v1.diff uploaded by bkruse (license 132)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115422 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This does not fix the bug reported, but I believe it is correct.
(from issue #12446)
Patches:
bug_12446.diff uploaded by snuffy (license 35)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115418 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115415 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115341 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12402)
Reported by: Corydon76
Patches:
20080410__no_verbose_in_rx_output.diff.txt uploaded by Corydon76 (license 14)
20080501__no_verbose_in_rx_output__1.4.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115333 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
or that speexdsp does. If both fail then speex stuff can not be built.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115327 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@115320 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115312 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is exactly backwards.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115308 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
switchvox.
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: http://svn.digium.com/svn/asterisk/branches/1.4@115304 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
........
r115296 | russell | 2008-05-05 12:53:26 -0500 (Mon, 05 May 2008) | 28 lines
Merge changes from team/russell/iax2_find_callno_1.2
These changes address a critical performance issue introduced in the latest
release. The fix for the latest security issue included a change that made
Asterisk randomly choose call numbers to make them more difficult to guess by
attackers. However, due to some inefficient (this is by far, an understatement)
code, when Asterisk chose high call numbers, chan_iax2 became unusable after
just a small number of calls. On a small embedded platform, it would not be
able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't
run more than about 16 IAX2 channels. Ouch.
These changes address some performance issues of the find_callno() function
that have bothered me for a very long time. On every incoming media frame,
it iterated through every possible call number trying to find a matching
active call. This involved a mutex lock and unlock for each call number
checked. So, if the random call number chosen was 20000, then every media
frame would cause 20000 locks and unlocks. Previously, this problem was
not as obvious since Asterisk always chose the lowest call number it could.
A second container for IAX2 pvt structs has been added. It is an astobj2
hash table. When we know the remote side's call number, the pvt goes into
the hash table with a hash value of the remote side's call number. Then,
lookups for incoming media frames are a very fast hash lookup instead of an
absolutely insane array traversal.
In a quick test, I was able to get more than 3600% more IAX2 channels
on my machine with these changes.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115297 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12525)
Reported by: explidous
Patches:
20080428__bug12525.diff.txt uploaded by Corydon76 (license 14)
Tested by: mvanbaak
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115285 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
are properly recognized.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115282 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
gives us.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115279 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
do this as GCC will just ignore the attribute and pop up a warning, it won't actually fail to compile.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115276 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reasons.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115257 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ignoring the way that macros expand. Instead, I have clarified in the
comment why the macro will work even if the scheduler id for the
task to be deleted changes during the execution of the macro.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115196 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115102 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10543)
Reported by: blitzrage
Patches:
20080418__bug10543.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115017 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
These changes address a critical performance issue introduced in the latest
release. The fix for the latest security issue included a change that made
Asterisk randomly choose call numbers to make them more difficult to guess by
attackers. However, due to some inefficient (this is by far, an understatement)
code, when Asterisk chose high call numbers, chan_iax2 became unusable after
just a small number of calls. On a small embedded platform, it would not be
able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't
run more than about 16 IAX2 channels. Ouch.
These changes address some performance issues of the find_callno() function
that have bothered me for a very long time. On every incoming media frame,
it iterated through every possible call number trying to find a matching
active call. This involved a mutex lock and unlock for each call number
checked. So, if the random call number chosen was 20000, then every media
frame would cause 20000 locks and unlocks. Previously, this problem was
not as obvious since Asterisk always chose the lowest call number it could.
A second container for IAX2 pvt structs has been added. It is an astobj2
hash table. When we know the remote side's call number, the pvt goes into
the hash table with a hash value of the remote side's call number. Then,
lookups for incoming media frames are a very fast hash lookup instead of an
absolutely insane array traversal.
In a quick test, I was able to get more than 3600% more IAX2 channels
on my machine with these changes.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114891 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Fix created in Huntsville together with Mark M (putnopvut)
(closes issue #12363)
Reported by: jvandal
Tested by: putnopvut, oej
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the size of the arrays can be adjusted in one place, and change the size of the arrays from 32768 calls to 2048 calls when LOW_MEMORY is defined
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114880 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
local ones (inspired by r578 of asterisk-addons by tilghman)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114875 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
channel's macrocontext
and macroexten fields. This is needed because if macros are daisy-chained, the incorrect
context and extension are placed on the new channel. I also added locking to the channel prior
to accessing these variables as noted in trunk's janitor project file.
(closes issue #12549)
Reported by: darren1713
Patches:
app_queue.c.macroextenpatch uploaded by darren1713 (license 116)
(with modifications from me)
Tested by: putnopvut
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114848 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
perfectly fine.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114829 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r114822 | kpfleming | 2008-04-29 07:52:32 -0500 (Tue, 29 Apr 2008) | 2 lines
stop script from appending source code if run multiple times
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114823 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
extension. Specifically check for this name, when we're checking if a module
is loaded.
(Closes issue #12534)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114708 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
may end up finding tds.h in /usr/local/include instead of /usr/include. If
this happens, the grep that looks for the version (from tdsver.h) will fail
and we'll have some problems during the build.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114695 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12528)
Reported by: pukepail
Patches:
patch.diff uploaded by pukepail (license 431)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114689 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also, remove some redundant logic I recently added in a fix.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114673 f38db490-d61c-443f-a65b-d21fe96a405b
|