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
dev-mode enabled. I have seen enough problems caused by this that I don't think
it's worth keeping. I want to continue to encourage anybody that is interested
to continue to run Asterisk from svn. Furthermore, I do not want their systems
to break when we change a structure definition in a header file. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
valid, therefore, those clients must be considered as buddies. The resource
string helps us make the distinction between clients.
Closes issue #10707, reported by yusufmotiwala.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
without resource from a buddy that is known to have a resource list.
Revert a change I previously made, where Asterisk could point to a
freed memory location.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@84890 65c4cc65-6c06-0410-ace0-fbb531ad65f3