The problem was that res_crypto now has a RWLIST named "keys". The macro
for defining this list defines a function used as a constructor for the list
called "init_keys". However, there was another function called init_keys in
this module for a CLI command. The fix is just to prepend the generated
functions with underscores.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78101 | russell | 2007-08-03 15:14:06 -0500 (Fri, 03 Aug 2007) | 10 lines
(closes issue #10194)
Reported by: blitzrage
Patches:
bug0010194 uploaded by vovochka
Tested by: blitzrage
Fix a problem when you call Voicemail() with multiple mailboxes specified and
ODBC_STORAGE is in use. The audio part of the message was only given to the
first mailbox specified.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78102 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78095 | russell | 2007-08-03 14:39:49 -0500 (Fri, 03 Aug 2007) | 28 lines
Add some improvements to lock debugging. These changes take effect
with DEBUG_THREADS enabled and provide the following:
* This will keep track of which locks are held by which thread as well as
which lock a thread is waiting for in a thread-local data structure. A
reference to this structure is available on the stack in the dummy_start()
function, which is the common entry point for all threads. This information
can be easily retrieved using gdb if you switch to the dummy_start() stack
frame of any thread and print the contents of the lock_info variable.
* All of the thread-local structures for keeping track of this lock information
are also stored in a list so that the information can be dumped to the CLI
using the "core show locks" CLI command. This introduces a little bit of a
performance hit as it requires additional underlying locking operations
inside of every lock/unlock on an ast_mutex. However, the benefits of
having this information available at the CLI is huge, especially considering
this is only done in DEBUG_THREADS mode. It means that in most cases where
we debug deadlocks, we no longer have to request access to the machine to
analyze the contents of ast_mutex_t structures. We can now just ask them
to get the output of "core show locks", which gives us all of the information
we needed in most cases.
I also had to make some additional changes to astmm.c to make this work when
both MALLOC_DEBUG and DEBUG_THREADS are enabled. I disabled tracking of one
of the locks in astmm.c because it gets used inside the replacement memory
allocation routines, and the lock tracking code allocates memory. This caused
infinite recursion.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78063 | russell | 2007-08-03 12:01:07 -0500 (Fri, 03 Aug 2007) | 4 lines
Only pass through HOLD and UNHOLD control frames when the mohinterpret option
is set to "passthrough". This was pointed out by Kevin in the middle of a
training session.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78028 | russell | 2007-08-02 21:04:22 -0500 (Thu, 02 Aug 2007) | 6 lines
Don't reuse the timespec that was set to 0 in the previous timedwait as it
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/trunk@78029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77949 | russell | 2007-08-02 14:25:14 -0500 (Thu, 02 Aug 2007) | 5 lines
Fix the case where a dynamic thread times out waiting for something to do
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/trunk@77950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10299)
........
r77947 | qwell | 2007-08-02 13:42:36 -0500 (Thu, 02 Aug 2007) | 5 lines
Make sure we clear the prompt status message on a hangup.
Also rearrange messages to better fit with what a wireshark trace shows it should be.
Issue 10299, initial patch and solution by sbisker, modified by me to fit with wireshark trace.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r77945 | murf | 2007-08-02 12:21:40 -0600 (Thu, 02 Aug 2007) | 9 lines
Merged revisions 77942 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r77942 | murf | 2007-08-02 11:56:37 -0600 (Thu, 02 Aug 2007) | 1 line
This patch hopefully solves 10141; The user is running with it, and it doesn't appear to harm asterisk's operation, and may prevent a crash. I'll store it in 1.2, as we have shut down support on 1.2, but since I developed the patch before support finished, and it might affect 1.4 and trunk, I'm going ahead with it.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77943 | russell | 2007-08-02 13:04:43 -0500 (Thu, 02 Aug 2007) | 9 lines
Fix another race condition in the handling of dynamic threads. If the dynamic
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/trunk@77944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
trunk version of find_idle_thread() where the old full frame processing
information was not cleared out. This would have caused full frames to get
deferred for processing by threads that weren't actually processing frames for
that call. Nice catch!!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10358)
........
r77894 | qwell | 2007-08-02 10:15:45 -0500 (Thu, 02 Aug 2007) | 5 lines
Make sure that we show the correct extension if dialed from a macro
"From: 5555" rather than "From: s"
Issue 10358, initial patch by DEA, reworked by me to use S_OR, tested by sbisker
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77887 | russell | 2007-08-01 17:16:17 -0500 (Wed, 01 Aug 2007) | 23 lines
Fix some race conditions which have been causing weird problems in chan_iax2.
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/trunk@77889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77883 | qwell | 2007-08-01 16:08:42 -0500 (Wed, 01 Aug 2007) | 7 lines
Fix an issue that caused one-way audio on some newer devices (specifically the 7921),
due to sending packets in the wrong order during hangup.
Also make sure we clear tones/messages on the correct line/instance.
Issue 10291, patch by DEA, tested by sbisker and myself.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r77871 | file | 2007-08-01 15:08:51 -0300 (Wed, 01 Aug 2007) | 4 lines
(closes issue #10351)
Reported by: ftarz
Some platforms don't like it when you pass NULL to vsnprintf so pass "" instead.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77854 | mmichelson | 2007-08-01 09:08:57 -0500 (Wed, 01 Aug 2007) | 8 lines
Fixes an issue I introduced to queues wherein a queue with joinempty=yes would kick people out of the queue because of erroneously
thinking the 'n' option was in use.
(closes issue #10320, reported by jfitzgibbon, patched by me, tested by blitzrage and me)
Thank you blitzrage for all the testing you've done lately with queues! It's much appreciated!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77852 | mmichelson | 2007-08-01 08:59:59 -0500 (Wed, 01 Aug 2007) | 7 lines
If a queue uses dynamic realtime members, then the member list should be updated after each attempt to call the queue.
This fixes an issue where if a caller calls into a queue where no one is logged in, they would wait forever even if a member
logged in at some point.
(closes issue #10346, reported by and tested by blitzrage, patched by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77853 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77824 | mmichelson | 2007-07-31 10:21:22 -0500 (Tue, 31 Jul 2007) | 6 lines
This patch makes Asterisk send 100 Trying provisional responses upon receipt of re-invites. This makes it so that if there are two or more Asterisk
servers between endpoints, the Asterisk servers will not keep retransmitting the re-invites.
(closes issue #10274, reported by cstadlmann, patched by me with approval from file)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Russell Bryant
Jason Parker
Steve Murphy
Joshua Colp
Mark Michelson
Kevin P. Fleming