A change was committed to fix direct media ACL support. This change wrongly assumed that
only a single channel technology structure exists for chan_sip. This is in fact false as
a second exists for calls using SIP INFO DTMF. The code which performs direct media ACL
checking now checks for both the non-INFO DTMF and INFO DTMF channel technology structures.
(closes issue ASTERISK-20409)
Reported by: michele cicciotti privatewave
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before this commit, __astman_get_header would blindly dereference the passed in
'struct message *' to traverse the header list. There are cases, however, such
as '*CLI> sip qualify peer foo' where the message pointer is NULL, so we need
to check for that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For SS7, the companding law for a call was chosen inconsistently depending
upon ss7type (ITU vs ANSI) and the DAHDI companding default (T1 vs E1).
For incoming calls, the companding law was determined by ss7type. For
outgoing calls, the companding law was determined by the DAHDI default.
With the wrong combination you would get A-law/u-law conflicts. An
A-law/u-law conflict sounds like bad static on the line.
SS7 ITU signaling with E1 line: ok
SS7 ITU signaling with T1 line: noise
SS7 ANSI signaling with E1 line: noise
SS7 ANSI signaling with T1 line: ok
* Fix the companding law used to be determined by the SS7 signaling type
only.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves two sources of memory leaks when using TLS in Asterisk:
1) It removes improper initialization (and multiple re-initializations) of
portions of the SSL library. Asterisk calls SSL_library_init and
SSL_load_error_strings during SSL initialization; collectively this
obviates the need for calling any of the following during initialization
or client connection handling:
* ERR_load_crypto_strings (handled by SSL_load_error_strings)
* OpenSSL_add_all_algorithms (synonym for SSL_library_init)
* SSLeay_add_ssl_algorithms (synonym for SSL_library_init)
2) Failure to completely clean up all memory allocated by Asterisk and by
the SSL library for TLS clients. This included not freeing the SSL_CTX
object in the SIP channel driver, as well as not clearing the error
stack when the TLS client exited.
Note that these memory leaks were found by Thomas Arimont, and this patch
was essentially written by him with some minor tweaks.
(closes issue AST-889)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
patches:
(bugAST-889.patch) by Thomas Arimont (license 5525)
Review: https://reviewboard.asterisk.org/r/2105
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373061 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_waitfordigit_full would simply pass its timeout to ast_waitfor_nandfds,
expecting it to decrement the timeout by however many milliseconds were
waited. This is a problem if it consistently waits less than 1ms. The timeout
will never be decremented, and we wait... FOREVER!
This patch makes ast_waitfordigit_full manage the timeout itself. It maintains
the previously undocumented behavior that negative timeouts wait forever.
(closes issue ASTERISK-20375)
Reported by: Mark Michelson
Tested by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2109/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When REF_DEBUG is enabled in certain files - most notably ccss.c - the 'tag'
parameter passed to __ao2_ref_debug will be a const char *. The function
currently expects that parameter to not be const. This causes a warning
when compiling, as the const qualifier is being discarded. With dev-mode
enabled, this prevents compiling Asterisk.
This patch makes __ao2_ref_debug's tag and file parameters const.
(closes issue ASTERISK-20408)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "autodestruct with owner in place" message is typically
indicative of a channel reference leak. Printing out the name
of the channel in the message may be helpful when trying to
debug the issue.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes chan_local channels to use an 8 digit hex identifier generated
atomically and sequentially in order to eliminate the chance of having
multiple channels with the same name during high call volume situations.
(issue ASTERISK-20318)
Reported by: Dan Cropp
Review: https://reviewboard.asterisk.org/r/2104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When channels get bridged due to an AMI bridge action
or a DTMF attended transfer, the two channels that
get bridged have their application data pointing to
the other channel's name. This means that if one channel
is hung up but the other moves on, it means that the
channel that moves on will have its application data
pointing at freed memory.
(issue ASTERISK-20335)
Reported by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When IAX2 debug was changed from iax_showframe to iax_outputframe,
some instances were missed (or added afterward). This was causing
debug output to not be displayed when expected.
(closes issue ASTERISK-20338)
Reported-by: John Covert
Patch-by: John Covert
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a CLI warning when a SDP offer is rejected due to UDPTL
initialization failure. Previously, there was no indication of the
reason for offer rejection in this case.
(closes issue ASTERISK-20357)
Reported-by: Francesco Usseglio Gaudi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the user would have a parkinglot set on a channel that
was parked and when the channel was retrieved, any attempt by that channel
to park would simply use the default. This patch makes parkinglot values
set in this way be retained through the masquerade.
(closes issue AST-990)
Reported by: Nick Huskinson
Patches:
masquerade_parkinglot_patch.diff Uploaded by Jonathan Rose (license 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r356604, SRTP handling was fixed to accomodate multiple crypto keys in an
SDP offer and the ability to re-create an SRTP session when the crypto keys
changed. In certain circumstances - most notably when a phone is put on
hold after having been bridged for a significant amount of time - the act
of re-creating the SRTP session causes problems for certain models of phones.
The patch committed in r356604 always re-created the SRTP session regardless
of whether or not the cryptographic keys changed. Since this is technically
not necessary, this patch modifies the behavior to only re-create the SRTP
session if Asterisk detects that the remote key has changed. This allows
models of phones that do not handle the SRTP session changing to continue
to work, while also providing the behavior needed for those phones that do
re-negotiate cryptographic keys.
In addition, in Asterisk 1.8 only, it was found that phones that offer
AES_CM_128_HMAC_SHA1_32 will end up with no audio if the phone is the
initiator of the call. The phone will send an INVITE request specifying
that AES_CM_128_HMAC_SHA1_32 be used for the cryptographic policy; Asterisk
will set its policy to that value. Unfortunately, when the call is Answered
and a 200 OK is sent back to the UA, the policy sent in the response's SDP
will be the hard coded value AES_CM_128_HMAC_SHA1_80. This potentially
results in Asterisk using the INVITE request's policy of
AES_CM_128_HMAC_SHA1_32, while the phone uses Asterisk's response of
AES_CM_128_HMAC_SHA1_80. Hilarity ensues as both endpoints think the other
is crazy.
This patch fixes that by caching the policy from the request and responding
with it. Note that this is not a problem in Asterisk 10 and later, as the
ability to configure the policy was added in that version.
(issue ASTERISK-20194)
Reported by: Nicolo Mazzon
Tested by: Nicolo Mazzon
Review: https://reviewboard.asterisk.org/r/2099
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this flag, those files will compile with the system installed
OpenSSL headers (if they exist). This is a real bummer if a different
path was specified using --with-ssl=
(closes issue ASTERISK-20392)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI action VoicemailUsersList VoicemailUserEntry event headers
ServerEmail and MailCommand did not report the global values if they were
not overridden. The VoicemailUserEntry event header ServerEmail was not
populated with the global value if the voicemail user did not override it.
The VoicemailUserEntry event header MailCommand was never populated with a
value.
* Removed unused struct ast_vm_user member mailcmd[].
(closes issue AST-973)
Reported by: John Bigelow
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous commit (r372554) was from a patch that was written before
r366880, which ensured that ast_str objects allocated in the sendmail
routine were free'd in off nominal paths. This commit frees the
string objects in the off nominal path introduced in r372554.
(issue ASTERISK-17133)
Reported by: Tzafrir Cohen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When MiniVM sends an e-mail and it has the volgain option set, it will spawn
sox in a separate process to handle the manipulation of the sound file. In
doing so, it creates a temporary file. There are two problems here:
1) The file descriptor returned from mkstemp is leaked
2) The finalfilename character pointer points to a buffer that loses scope
once volgain processing is finished.
Note that in r316265, Russell fixed some gcc warnings by using the return
value of the mkstemp call. A warning was placed in minivm that the file
descriptor was going to be leaked. This patch reverts that change, as it
handles the leak and 'uses' the file descriptor returned from mkstemp.
(closes issue ASTERISK-17133)
Reported by: Tzafrir Cohen
patches:
minivm_18501_demo.diff uploaded by Tzafrir Cohen (license #5035)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using tab-completion for the list of queues on "queue reset stats"
or "queue reload {all|members|parameters|rules}", the tab-completion
listing for further queues erroneously listed queues that had already
been added to the list. The tab-completion listing now only displays
queues that are not already in the list.
(closes issue AST-963)
Reported-by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to 1.8, it was not necessary for an explicit "type" to be set for an
asterisk LDAP realtime peer. Now the routine find_peer actually checks the
type field during registration and fails to find the peer if it is not set.
The attached patches make the realtime type equal whatever type is being
searched for if the type is 0 upon return from routine build_peer.
(closes issue ASTERISK-17222)
Reported by: John Covert
Patch by: David Vossel
Tested by: Darren Sessions
Review: https://reviewboard.asterisk.org/r/2095/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r366547 introduced a change to the directmedia ACL for chan_sip which
modified the behavior significantly. Prior to the patch, this option would
bridge peers with directmedia if a peer's IP address matched its own
directmedia ACL. After that patch, the peer would check the bridged peer's
ACL instead. This change has been present since 1.8.14.0. That patched failed
to document the change in Upgrade.txt, so this patch adds mention of that
change to UPGRADE.txt (UPGRADE-1.8.txt in newer branches)
(issue AST-876)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, tabbing at the end of "queue show" produced a list of
available queues about which information could be shown, but did not
include an alternative command, "rules", to access information about
queue rules. The "rules" item should now be shown in the list of
tab-completable items.
(closes issue AST-958)
Reported-by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consider a scenario where DUNDi peer PBX1 has two peers that are its neighbors,
PBX2 and PBX3, and where PBX2 and PBX3 are also neighbors. If the connection
is temporarily broken between PBX1 and PBX3, PBX1 should not include PBX3 in
the list of peers it sends to PBX2 in a DPDISCOVER message, as it cannot send
messages to PBX3. If it does, PBX2 will assume that PBX3 already received the
message and fail to forward the message on to PBX3 itself. This patch fixes
this by only including peers in a DPDISCOVER message that are reachable by the
sending node. This includes all peers with an empty address
(00:00:00:00:00:00) and that are have been reached by a qualify message.
This patch also prevents attempting to qualify a dynamic peer with an empty
address until that peer registers.
The patch uploaded by Peter was modified slightly for this commit.
(closes issue ASTERISK-19309)
Reported by: Peter Racz
patches:
dundi_routing.patch uploaded by Peter Racz (license 6290)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When parsing a 'number' defined in followme.conf, FollowMe previously parsed
the number in the configuration file into a buffer with a length of 90
characters. This can artificially limit some parallel dial scenarios. This
patch allows for numbers of any length to be defined in the configuration
file.
Note that Clod Patry originally wrote a patch to fix this problem and received
a Ship It! on the JIRA issue. The patch originally expanded the buffer to 256
characters. Instead, the patch being committed duplicates the string in the
config file on the stack before parsing it for consumption by the application.
(closes issue ASTERISK-16879)
Reported by: Clod Patry
Tested by: mjordan
patches:
followme_no_limit.diff uploaded by Clod Patry (license #5138)
Slightly modified for this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation incorrectly listed 'rtp' as a reloadable subsystem
and left out many other reloadable subsystems. It is now also
documented that subsystems may only be reloaded, not loaded or
unloaded.
(closes issue AST-977)
Reported-by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When manager_show_dialplan_helper was written, the counter increment
for the total number of contexts was placed with the extensions
increment instead of in the enclosing loop. This function should
now generate correct context counts.
(closes issue AST-970)
Reported-by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two memory leaks:
1. When find_user is called with NULL as its first parameter, the voicemail
user returned is allocated on the heap. The inboxcount2 function uses
find_user in such a fashion when counting new messages, and fails to free
the resulting voicemail user object.
2. When populate_defaults is called on a voicemail user, it wipes whatever
flags have been set on the object by copying over the global flags object.
If the VM_ALLOCED flag was ste on the voicemail user prior to doing so,
that flag is removed. This leaks the voicemail user when free_user is later
called.
(closes issue ASTERISK-19155)
Reported by: Filip Jenicek
patches:
asterisk.patch2 uploaded by Filip Jenicek (license 6277)
Patch slightly modified for this commit.
Review: https://reviewboard.asterisk.org/r/2096
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revert DTMF hit/miss detector to original -r349249 method with some changes, remove unnecessary;
1. reseting of hits=0, when no signal, only need to set it once.
2. incrementing of hits, when the hit is the same as the current hit.
3. setting of lasthit, when it's the same as before.
Change HITS_TO_BEGIN to 2, MISSES_TO_END to 3
& 3 spelling mistakes
(closes issue ASTERISK-19610)
alecdavis (license 585)
Reported by: Jean-Philippe Lord
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/2085/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372239 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 1.4+, a fix was put in place to increment the sequence number for
retransmitted DTMF end packets. With the introduction of the RTP engine API in
1.8, the sequence number was no longer being incremented. This patch fixes this
regression as well as cleans up a few lines that were not doing anything.
(closes issue ASTERISK-20295)
Reported by: Nitesh Bansal
Tested by: Michael L. Young
Patches:
01_rtp_event_seq_num.patch uploaded by Nitesh Bansal (license 6418)
asterisk-20295-dtmf-fix-cleanup.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PQClear is not called when the result object of a call to PQExec has a
status of PGRES_COMMAND_OK. Interestingly enough, the off nominal case was
handled properly, so this memory leak only occurred when CEL records were
successfully written.
This patch properly clears the result in the nominal code path.
(closes issue ASTERISK-19991)
Reported by: Etienne Lessard
Tested by: Etienne Lessard
patches:
mem_leak_cel_pgsql.patch uploaded by Etienne Lessard (license #6394)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When app_queue is unloaded, the queues container has its refcount
decremented, potentially to 0. Then the taskprocessor responsible
for handling device state changes is unreferenced. If the
taskprocessor happens to be just about to run its task, then it
will create and destroy an iterator on the queues container.
This can cause the refcount on the queues container to increase to
1 and then back to 0. Going back to 0 a second time results in
double frees.
This failure was seen periodically in the testsuite when Asterisk
would shut down.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Queue member status would not always get updated properly when the member
was called, thus resulting in the member getting multiple calls. With this
change, we update the member's status at the time of calling, and we also
check to make sure the member is still available to take the call before
placing an outbound call.
(closes issue ASTERISK-16115)
reported by nik600
Patches:
app_queue.c-svn-r370418.patch uploaded by Italo Rossi (license #6409)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an IAX2 call is made using the credentials of a peer defined in a dynamic
Asterisk Realtime Architecture (ARA) backend, the ACL rules for that peer are
not applied to the call attempt. This allows for a remote attacker who is aware
of a peer's credentials to bypass the ACL rules set for that peer.
This patch ensures that the ACLs are applied for all peers, regardless of their
storage mechanism.
(closes issue ASTERISK-20186)
Reported by: Alan Frisch
Tested by: mjordan, Alan Frisch
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI Originate action can allow a remote user to specify information that can
be used to execute shell commands on the system hosting Asterisk. This can
result in an unwanted escalation of permissions, as the Originate action, which
requires the "originate" class authorization, can be used to perform actions
that would typically require the "system" class authorization. Previous attempts
to prevent this permission escalation (AST-2011-006, AST-2012-004) have sought
to do so by inspecting the names of applications and functions passed in with
the Originate action and, if those applications/functions matched a predefined
set of values, rejecting the command if the user lacked the "system" class
authorization. As noted by IBM X-Force Research, the "ExternalIVR"
application is not listed in the predefined set of values. The solution for
this particular vulnerability is to include the "ExternalIVR" application in the
set of defined applications/functions that require "system" class authorization.
Unfortunately, the approach of inspecting fields in the Originate action against
known applications/functions has a significant flaw. The predefined set of
values can be bypassed by creative use of the Originate action or by certain
dialplan configurations, which is beyond the ability of Asterisk to analyze at
run-time. Attempting to work around these scenarios would result in severely
restricting the applications or functions and prevent their usage for legitimate
means. As such, any additional security vulnerabilities, where an
application/function that would normally require the "system" class
authorization can be executed by users with the "originate" class authorization,
will not be addressed. Instead, the README-SERIOUSLY.bestpractices.txt file has
been updated to reflect that the AMI Originate action can result in commands
requiring the "system" class authorization to be executed. Proper system
configuration can limit the impact of such scenarios.
(closes issue ASTERISK-20132)
Reported by: Zubair Ashraf of IBM X-Force Research
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r294740, the CODING-GUIDELINES was removed from the doc folder in favor
of the content on the Asterisk wiki. Some folks still look in the doc folder
initially for coding guideline suggestions; as such, this patch adds a
CODING-GUIDELINES file back into the doc folder. The content of the file
merely points to the correct page on the Asterisk wiki where the coding
guidelines currently live.
(closes issue ASTERISK-20279)
Reported by: Andrew Latham
Patches:
CODING-GUIDELINES.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dummy channels usually aren't read from, but functions like SHELL and CURL
use autoservice on the channel.
(closes issue ASTERISK-20283)
Reported by: Gareth Palmer
Patches:
svn-371580.patch (license #5169) patch uploaded by Gareth Palmer (modified)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The v1.8 -r369258 change to fix the F and F(x) action logic introduced a
regression in passing the hangup cause from the called channel to the
caller channel.
(closes issue ASTERISK-20287)
Reported by: Konstantin Suvorov
Patches:
app_dial_hangupcause.patch (license #6421) patch uploaded by Konstantin Suvorov (modified)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation made it sound as if the DTMF acknowledgment was needed
at the time the agent logs in, rather than when the agent is called. This
is likely a relic from the days when there were multiple ways of logging
in agents.
(closes issue AST-962)
reported by Steve Pitts
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "Waiting" field was misdocumented as reporting the number of
messages waiting. In reality, it simply indicated the presence or
absence of waiting messages.
(closes issue AST-975)
reported by John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371782 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original implementations simply wrap pthread functions, which take
absolute time as an argument. The spinlock version for systems without
those functions treated the argument as a delta. This patch fixes the
spinlock version to be consistent with the pthread version.
(closes issue ASTERISK-20240)
Reported by: Egor Gorlin
Patches:
lock.c.patch uploaded by Egor Gorlin (license 6416)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When compiling with BETTER_BACKTRACES enabled, Asterisk will sometimes
crash when "core show locks" is run. This happens regularly in the
testsuite since several tests run "core show locks" to help with
debugging. This seems to be a fault with libraries on certain operating
systems (notably CentOS 6.2/6.3) running on virtual machines and
utilizing gcc 4.4.6.
(closes issue ASTERISK-20090)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@371690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
