and modify channel data that may change elsewhere. I went through every timer
callback in the source tree to make sure that none of them did any additional
locking that could introduce deadlocks, and all is well.
(closes issue #10765)
Reported by: Ivan
Patches:
ast_1_4_11_svn_patch_channel_rc.diff uploaded by Ivan (license 229)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
me in issue #11018, doesn't really make sense. There is no reason to have
the base64 decode function force a '\0' terminated buffer, when the result is
almost always binary, anyway. In fact, this caused some breakage, as some code
in res_crypto passed in a buffer exactly the right size to get its binary
result, which got stomped on by this patch.
(closes issue #11018, reported by dimas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since the code attempts to set the strategy to -1 if you specify a bogus strategy.
While this isn't a huge issue in 1.4, it could be a problem for someone who, say, tries
to use the roundrobin strategy in trunk (despite all the deprecation warnings in 1.4).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
not thread safe. How ironic! Anyway, these changes ensure that the code that
is accessing the lock debugging data is thread-safe.
Many thanks to Ivan for finding and fixing the core issue here, and also
thanks to those that tested the patch and provided test results.
(closes issue #10571)
(closes issue #10886)
(closes issue #10875)
(might close some others, as well ...)
Patches: (from issue #10571)
ivan_ast_1_4_12_rel_patch_lock.h.diff uploaded by Ivan (license 229)
- a few small changes by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
interesting (read nasty) situations. This patch clears up the issue by making
only dynamic queue members removable via dynamic methods.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change. I changed this a while ago in trunk for performance reasons. However,
bug 8407 points out that it is actually a race condition, causing device state
changes to get processed in random order. So, I backported my changes from
trunk to 1.4.
(closes issue #8407, patch provided by tim_ringenbach, committed patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
some amount of time. Be a little bit more careful and prepare all of the
output in an intermediary buffer while holding a global resource. Then, after
releasing it, send the output to ast_cli().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sense for it to default to off. The default configuration file has it on, and
proper RFC behavior, as indicated by a comment in the code, is for it to be on.
So, let's have it on by default to make lives easier.
(closes issue #10954, suggested by jtodd)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85604 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and retrieve its output. The issue was that there was no way for the main Asterisk
process to know that the remote console was connecting in the -rx mode. The way that
James has fixed this is to have all remote consoles muted by default. Then, regular
remote consoles automatically execute a CLI command to unmute themselves when they
first start up.
(closes issue #10847)
Reported by: atis
Patches:
asterisk-consolemute.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CLI command at once for a remote console.
(closes issue #10888)
Reported by: jamesgolovich
Patches:
asterisk-climultiple.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85532 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the middle of the struct, instead of at the end. One of the Debian folks,
paravoid, pointed out that this breaks binary compatability with modules
compiled against older headers. So, I'm moving the new member to the end
of the struct to resolve the situation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
