UpdateConfig manager action is issued and the
file specified in DstFileName does not yet exist,
an error is not returned.
(closes issue #13341)
Reported by: vadim
Patches:
13341.patch uploaded by putnopvut (license 60)
(with small modification from seanbright)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@139769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@139635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ChanSpy and specify a spy group, and sit in the application long enough looping
through the channel list, you will eventually run out of stack space and the
application with exit with a seg fault. The backtrace was always inside of
a harmless snprintf() call, so it was tricky to track down. However, it turned
out that the call to snprintf() was just the biggest stack consumer in this
code path, so it would always be the first one to hit the boundary.
(closes issue #13338)
Reported by: ruddy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@139213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(from what the corresponding channel variables were set to)
when the agent logs out.
(closes issue #13098)
Reported by: davidw
Patches:
20080731__issue13098_agent_ackcall_not_reset.diff uploaded by bbryant (license 36)
Tested by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
buffers=<num of buffers>,<policy>
Where the number of buffers is some non-negative integer and the policy is either "full", "half", or "immediate".
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
lock to ensure that no other threads still have it locked. While
this should not happen under normal circumstances, it appears that
if the spyer and spyee hang up at nearly the same time, the following
may occur.
1. ast_channel_free is called on the spyee's channel.
2. The chanspy datastore is removed from the spyee's channel in
ast_channel_free.
3. In the spyer's thread, the spyer attempts to remove and destroy the datastore
from the spyee channel, but the datastore has already been removed in step 2,
so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy callback,
chanspy_ds_destroy. This involves locking the chanspy_ds.
5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4,
the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock
which is currently locked by another thread.
The backtrace provided in issue #12969 supports the idea that this is possible
(and has even occurred). This commit does not close the issue, but should help
in preventing one type of crash associated with the use of app_chanspy.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to timeouts from being strict to non-strict for more
accuracy.
(closes issue #13239)
Reported by: atis
Patches:
app_queue_timeouts_v2.patch uploaded by atis (license 242)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@138027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the existing channel name without the "Zap/" or "DAHDI/" prefix, since our
test string is also without that prefix.
(closes issue #13027)
Reported by: dferrer
Patches:
chan_zap-1.4.21.1_fix2.patch uploaded by dferrer (license 525)
(Slightly modified by me, to compensate for both names)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@137847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CDR(userfield) if it is set. The new behavior is to check for the userfield
column on module load, and if it exists, we will store CDR(userfield) when
CDRs are written. A similar patch already went into trunk and 1.6.0.
(closes issue #13290)
Reported by: falves11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@137348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin P. Fleming
Jeff Peeler
Sean Bright
Terry Wilson
Mark Michelson
Steve Murphy
Philippe Sultan
Russell Bryant
Shaun Ruffell
Tilghman Lesher