| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119354 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
of opportunity
for a DTMF frame, or some other deferred frame type, to come in and get dropped.
(closes issue #12656)
(closes issue #12656)
Reported by: dimas
Patches:
v3-12656.patch uploaded by dimas (license 88)
-- with some modifications by me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119156 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
|
|
accomplishes the same goal in a better way.
(issue #12470)
Reported By: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114230 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
(closes issue #12266, reported by dimas)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@110395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
now is stuff that I have written recently ...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105565 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
These changes fix up some dubious code that I came across while auditing what
happens in the autoservice thread when there are no channels currently in
autoservice.
1) Change it so that autoservice thread doesn't keep looping around calling
ast_waitfor_n() on 0 channels twice a second. Instead, use a thread condition
so that the thread properly goes to sleep and does not wake up until a
channel is put into autoservice.
This actually fixes an interesting bug, as well. If the autoservice thread
is already running (almost always is the case), then when the thread goes
from having 0 channels to have 1 channel to autoservice, that channel would
have to wait for up to 1/2 of a second to have the first frame read from it.
2) Fix up the code in ast_waitfor_nandfds() for when it gets called with no
channels and no fds to poll() on, such as was the case with the previous code
for the autoservice thread. In this case, the code would call alloca(0), and
pass the result as the first argument to poll(). In this case, the 2nd
argument to poll() specified that there were no fds, so this invalid pointer
shouldn't actually get dereferenced, but, this code makes it explicit and
ensures the pointers are NULL unless we have valid data to put there.
(related to issue #12116)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105563 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the list of channels in autoservice. The problem was that it was possible for
a channel to get removed from autoservice and destroyed, while the autoservice
thread was still messing with the channel. This led to memory corruption, and
caused crashes. This explains multiple backtraces I have seen that have
references to autoservice, but do to the nature of the issue (memory corruption),
could cause crashes in a number of areas.
(fixes the crash in BE-386)
(closes issue #11694)
(closes issue #11940)
The following issues could be related. If you are the reporter of one of these,
please update to include this fix and try again.
(potentially fixes issue #11189)
(potentially fixes issue #12107)
(potentially fixes issue #11573)
(potentially fixes issue #12008)
(potentially fixes issue #11189)
(potentially fixes issue #11993)
(potentially fixes issue #11791)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105409 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Closes issue #11694)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97194 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
autoservice, remember it and ensure that the channel has the same setting when
autoservice gets stopped. (pointed out by d1mas, patched up by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94801 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
we only care about the END of a digit. That way, no magic digit emulation stuff
will happen when all we're doing is queueing up END frames.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94797 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
going to make ast_read() do a lot of extra work when the channel comes back
out of autoservice.
(closes issue #11628, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@94790 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91777 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91737 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
autoservice and autoservice was already on, it would erroneously return an
error.
Reported by: adiemus
Patch by: dimas
(Closes issue #11433)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90432 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89886 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This set of changes fixes an issue that was reported to me on IRC yesterday.
The user, d1mas, was using chan_zap for incoming calls and was having DTMF
recognition issues in some situations. Specifically, he noticed that the
problem occurred when using DISA or WaitExten. He also noticed that when
using Read, the problem did not occur. His system also used DUNDi for
dialplan lookups.
So, he theorized that if the DUNDi lookups blocked for some period of time,
that audio from the zap channel could get lost. If the audio got lost, then
it wouldn't be run through the DTMF detector, and digits could get lost.
He was correct, and the following set of changes fixes the problem. However,
the changes go a little bit further than what was necessary to fix this exact
problem.
1) I updated pbx_extension_helper() to autoservice the associated channel to
handle cases where extension lookups may take a long time. This would
normally be a dialplan switch that does some lookup over the network, such
as the DUNDi or IAX2 switches.
This ensures that even while a DUNDi lookup is blocking, the channel will be
continuously serviced.
2) I made a change to the autoservice code. This is actually something that
has bothered me for a long time. When a channel is in autoservice, _all_
frames get thrown away. However, some frames really shouldn't be thrown
away. The most notable examples are signalling (CONTROL) frames, and DTMF.
So, this patch queues up important frames while a channel is in autoservice.
When autoservice is stopped on the channel, the queued up frames get stuck
back on the channel so that they can get processed instead of thrown away.
3) I made another change to the autoservice code to handle the case where
autoservice is started on channels recursively.
Previously, you could call ast_autoservice_start() multiple times on a
channel, and it would stop the first time ast_autoservice_stop() gets
called. Now, it will ensure that autoservice doesn't actually stop until
the final call to ast_autoservice_stop().
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89790 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reduce standard thread stack size slightly to allow the pthreads library to allocate the stack+data and not overflow a power-of-2 allocation in the kernel and waste memory/address space
add a new stack size for 'background' threads (those that don't handle PBX calls) when LOW_MEMORY is defined
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@44378 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
- restructured build tree and makefiles to eliminate recursion problems
- support for embedded modules
- support for static builds
- simpler cross-compilation support
- simpler module/loader interface (no exported symbols)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@40722 f38db490-d61c-443f-a65b-d21fe96a405b
|
