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
track mutexes unless they were declared using AST_MUTEX_DEFINE_STATIC. Locks
initialized with ast_mutex_init() were not tracked. It should work now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: bhowell
Add note to sample configuration about module load order and how it can cause perfectly good queue members to be marked as invalid.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. instead of using inboxcount as the core message counting function, we use messagecount instead. This makes it possible to count messages in folders besides just INBOX and Old.
2. inboxcount and hasvoicemail now use messagecount as their means of determining return values.
3. Added a copy_message function for IMAP storage. Unfortunately I don't have the means to test it, but it seems like a pretty straightforward function.
4. Removed a #ifndef IMAP_STORAGE and matching #endif from leave_voicemail for a couple of reasons. One, we want to support copying mail to multiple IMAP boxes, and two, IMAP was
broken because a STORE macro had been moved into this section of code.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
comment for this to be fixed for IMAP_STORAGE, as well. I left IMAP alone
since I know MarkM was working on this code right now for another reason.
This is broken even worse in trunk, but for a different reason. The fact
that the mailbox option supported multiple mailboxes is completely not obvious
from the code in the channel drivers. Anyway, I will fix that in another
commit ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
conference and options that use DTMF to activate various features. The problem
was that the BEGIN frame would be passed through, but the END frame would get
intercepted to activate a feature. Then, the other conference members would hear
DTMF for forever, which they didn't seem to like very much.
(closes issue #10400, reported by stevefeinstein, fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: wdecarne
Now that we pass through RTP timestamp information we need to make the allowed timestamp skew considerably less. There are situations where a source may change and due to the timestamp difference the receiver will experience an audio gap since we did not indicate by setting the marker bit that the source changed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now matches are made on both the IP address and port number, or if the insecure setting is set to "port" then just match on the
IP address.
In order to accomplish this, I also added a new API call, ast_category_root, which returns the first variable of an ast_category struct
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@78101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@78095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
