The CEL data structures need to be protected during a configuration reload
and shutdown. Asterisk crashed during a shutdown because CEL events were
still in flight and the CEL data structures were already destroyed.
* Protected the cel_backends, cel_dialstatus_store, and cel_linkedids ao2
containers with a global ao2 object wrapper.
* Added NULL checks before use of the cel_backends, cel_dialstatus_store,
and cel_linkedids ao2 containers in case the CEL module is already
shutdown.
* Fixed overloading of the cel_linkedids held objects reference count.
During shutdown any held objects would be leaked.
* Fixed memory leak of cel_linkedids held objects if the LINKEDID_END is
not being tracked. The objects in the cel_linkedids container were not
removed if the LINKEDID_END event is not used.
* Added access protection to the cel_backends container during the CLI
"cel show status" command.
* Made cel_backends, cel_dialstatus_store, and cel_linkedids use the
standard ao2 callback templates for the hash and cmp functions.
* Eliminated unnecessary uses of RAII_VAR().
* Made ast_cel_engine_init() cleanup alocated resources on failure.
(closes issue AST-1253)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3128/
........
Merged revisions 406417 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 406418 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 406465 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a crash when CELGenUserEvent is called from the dialplan
while CEL is disabled. Currently, CEL does not create its topics and
forwards if it is not enabled and external entities may depend on
these topics blindly since they should always be available. This patch
breaks up route creation and topic/forward creation such that the CEL
topics and forwards will always exist while the router and its
associated routes will be torn down and recreated as necessary.
(closes issue ASTERISK-22799)
Review: https://reviewboard.asterisk.org/r/3010/
Reported by: Matt Jordan
........
Merged revisions 402838 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r397921 | mmichelson | 2013-08-29 10:42:10 -0500 (Thu, 29 Aug 2013) | 6 lines
Resolve assumptions that bridge snapshots would be non-NULL for transfer stasis events.
Attempting to transfer an unbridged call would result in crashes in either CEL code or
in the conversion to AMI messages.
........
r397922 | mmichelson | 2013-08-29 10:42:29 -0500 (Thu, 29 Aug 2013) | 3 lines
Remove extra debug message.
........
Merged revisions 397921-397922 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This modifies the behavior of the CEL engine to conform to documented
behavior for Asterisk 12 as defined on the wiki
https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CEL+Specification
The primary changes deal with removal of the peer field from function
calls since it is no longer directly relevant to the bridging system
and removal of the layer of CDR-like business logic that was providing
a partial emulation of Asterisk 11 CEL functionality. With this change,
there is no longer a distinction between "bridges" and "conferences"
and all participation changes are denoted with bridge enter and bridge
exit messages.
This updates the CEL unit tests to handle these changes and simplifies
some of the macros used in the process.
This also fixes a segfault when attempting to ref a configuration that
failed to load.
Review: https://reviewboard.asterisk.org/r/2788/
(issue ASTERISK-21567)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
"implementation detail flag" on the channel technology. This tells
consumers of Stasis that the creation of this channel is an implementation
detail in Asterisk and can be ignored (if they so choose). This
consolidates the conference recorder/announcer flags as well - these flags
had no additional meaning beyond "ignore this channel please".
2. It modifies allocation of a channel in two ways:
(a) If a channel technology can be determined from the name, we set it
directly in the allocation routine. This prevents the initial
publication of the message from going out with a NULL channel technology
where possible. This lets Stasis consumers get the right channel
technology on the first publication.
(b) It reorganizes allocation to make use of the 'finalized' property on the
channel. This was already used to know that a channel had completely
finished its construction in the masquerade routine; now we also use it
to know whether or not the setting of certain channel properties is
occurring during or post construction. The various set routines were
modified accordingly as well.
3. The masquerade event is now dead, Jim. It no longer served any purpose
whatsoever - if you perform a call pickup you'll get a Pickup event;
if you perform an attended transfer you will still get those events; if you
steal a channel to put it elsewhere you'll get the corresponding NewExten or
BridgeEnter events.
Review: https://reviewboard.asterisk.org/r/2740
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable.
* There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place.
(closes issue ASTERISK-22193)
reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/2712
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This greatly modifies the operation of DTMF attended transfers so that
the full range of options from features.conf applies.
In addition, a new option has been added that allows for a transferer
to switch between bridges during a transfer before completing the
transfer.
(closes issue ASTERISK-21543)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2654
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a new CEL event type, AST_CEL_LOCAL_OPTIMIZE, to represent
local channel optimizations. Local channel optimizations were one of
several things conveyed by the now defunct BRIDGE_UPDATE event type.
This also adds a unit test to test generation of this new CEL event.
Review: https://reviewboard.asterisk.org/r/2676/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds new flags to the channel tech properties that flag it as
different types of implementation detail used exclusively to provide a
feature. Examples of channels that would have these flags include the
announcement and recording channels used by confbridge which are the
only two marked as such by this patch.
Review: https://reviewboard.asterisk.org/r/2633/
(closes issue ASTERISK-21873)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is hungup, both an APP_END event and a HANGUP event can be
fired. To ensure that HANGUP events occur after APP_END events, the method
callbacks for the APP_END event should be processed prior to the callbacks
for the HANGUP event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This process also involved a large amount of rework regarding how to redial
the Parker when a channel leaves a parking lot due to timeout. An attended
transfer channel variable has been added to attended transfers to extensions
that will eventually park (but haven't at the time of transfer) as well.
This resolves one of the two BUGBUG comments remaining in res_parking.
(issues ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2638/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds several unit tests for CEL functionality and provides the
requisite framework for creating additional unit tests.
This also cleans up some reference leaks that were occurring in
Stasis-Core message callback code.
Review: https://reviewboard.asterisk.org/r/2646/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be
used because masquerade situations are now accounted for in other ways.
This also refactors usage of AST_CEL_FORWARD to be produced by a Dial
message which has been extended with a "forward" field.
(closes issue ASTERISK-21566)
Review: https://reviewboard.asterisk.org/r/2635/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following memory/ref counting leaks:
* main/devicestate.c - unsubscribe and join our devicestate message
subscription
* main/cel.c - clean up the datastore and config objects on exist
* main/parking.c - cleanup memory leak of retriever snapshot on message
payload destruction
* res/parking/parking_bridge.c - cleanup memory leak of retrieve snapshot
on message payload destruction
* main/presencestate.c - unsubscribe and join the caching topic on exit
* manager.c - properly unregister the manager action "BlindTransfer"
* sorcery.c - shutdown the threadpool on exit and dispose of any wizards
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
cel.patch uploaded by jhardin (license #6512)
devicestate.patch uploaded by jhardin (license #6512)
manager.patch uploaded by jardin (license #6512)
presencestate.patch uploaded by jhardin (license #6512)
retriever-channel-snapshot.patch uploaded by jhardin (license #6512)
sorcery.patch uploaded by jhardin (license #6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This finishes moving all CEL linkedid tracking entirely within cel.c
since that is now possible with channel snapshots.
This also removes another CEL linkedid manipulation function from cel.h
that has already been internalized and is neither called nor available
to link against.
Review: https://reviewboard.asterisk.org/r/2632/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Properly search for bridge association structures so that they are
found when expected and handle cases where they don't exist.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This pulls bridge-related CEL event triggers out of the code in which
they were residing and pulls them into cel.c where they are now
triggered by changes in bridge snapshots. To get access to the
Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking
init have been pulled into core Asterisk init.
This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates
a two-party bridge has transitioned to a multi-party conference. The
reverse cannot occur in CEL terms even though it may occur in actuality
and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be
treated as multi-party conferences for the duration of the bridge.
Review: https://reviewboard.asterisk.org/r/2563/
(closes issue ASTERISK-21564)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END
Retirement of Linked IDs is also refactored.
CEL configuration has been refactored to use the config framework.
Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.
Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking. Commit other cleanups from multi-version Doxygen testing. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To fix a memory leak in CEL, a channel datastore was introduced whose
destruction function pointer was pointed to the ast_free macro. Without
MALLOC_DEBUG enabled this compiles as fine, as ast_free is defined as free.
With MALLOC_DEBUG enabled, however, ast_free takes on a definition from a
different place then utils.h, and became undefined. This patch resolves this
by using a reference to ast_free_ptr. When MALLOC_DEBUG is enabled, this
calls ast_free; when MALLOC_DEBUG is not enabled, this is defined to be
ast_free, which is defined to be free.
(issue AST-916)
Reported by: Thomas Arimont
........
Merged revisions 370273 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370274 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A customer reported a significant memory leak using Asterisk 1.8. They
have tracked it down to ast_cel_fabricate_channel_from_event() in
main/cel.c, which is called by both in-tree CEL logging modules
(cel_custom.c and cel_sqlite3_custom.c) for each and every CEL event
that they log.
The cause was an incorrect assumption about how data attached to an
ast_channel would be handled when the channel is destroyed; the data
is now stored in a datastore attached to the channel, which is
destroyed along with the channel at the proper time.
(closes issue AST-916)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2053/
........
Merged revisions 370205 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370206 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes to situations that could cause the CEL LINKEDID_END event to
be missed.
1) During a core stop gracefully, modules are unloaded when ast_active_channels
== 0. The LINKDEDID_END event fires during the channel destructor. This means
that occasionally, the cel_* module will be unloaded before the channel is
destroyed. It seemed generally useful to wait until the refcount of all
channels == 0 before unloading, so I added a channel counter and used it in the
shutdown code.
2) During a masquerade, ast_channel_change_linkedid is called. It calls
ast_cel_check_retire_linkedid which unrefs the linkedid in the linkedids
container in cel.c. It didn't ref the new linkedid. Now it does.
Review: https://reviewboard.asterisk.org/r/1900/
........
Merged revisions 367292 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367299 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r365006 | twilson | 2012-05-02 10:49:03 -0500 (Wed, 02 May 2012) | 12 lines
Fix a CEL LINKEDID_END race and local channel linkedids
This patch has the ;2 channel inherit the linkedid of the ;1 channel and fixes
the race condition by no longer scanning the channel list for "other" channels
with the same linkedid. Instead, cel.c has an ao2 container of linkedid strings
and uses the refcount of the string as a counter of how many channels with the
linkedid exist. Not only does this eliminate the race condition, but it also
allows us to look up the linkedid by the hashed key instead of traversing the
entire channel list.
Review: https://reviewboard.asterisk.org/r/1895/
........
r365068 | twilson | 2012-05-02 12:02:39 -0500 (Wed, 02 May 2012) | 11 lines
Don't leak a ref if out of memory and can't link the linkedid
If the ao2_link fails, we are most likely out of memory and bad things
are going to happen. Before those bad things happen, make sure to clean
up the linkedid references.
This patch also adds a comment explaining why linkedid can't be passed
to both local channel allocations and combines two ao2_ref calls into 1.
Review: https://reviewboard.asterisk.org/r/1895/
........
Merged revisions 365006,365068 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365083 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Everything still compiled after making these changes, so I assume these
whitespace-only changes didn't break anything (and shouldn't have).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Kevin Harwell
David M. Lee
Mark Michelson
Kinsey Moore
Matthew Jordan
Jonathan Rose
Andrew Latham
Kevin P. Fleming
Terry Wilson