The remote console continued to have issues with its output. In this case CLI
command output would either not show up (if verbose level = 0) or would contain
verbose prefixes (if verbose level > 0) once log messages were sent to the
remote console. The fix now now adds verbose prefix data to all new lines
contained in a verbose log string.
(closes issue ASTERISK-22450)
Reported by: David Brillert
(closes issue AST-1193)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2825/
........
Merged revisions 399267 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was an unintentional consequence of the update of features.conf to use the
config framework in Asterisk 12. Thanks to Marco Signorini on the Asterisk
developers list for pointing out the problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some channels exist merely as an implementation detail in Asterisk, such as
ConfBridge's announcer/recorder channels. These channels should never be
exposed to the outside world, or to interfaces that report on Asterisk. We
already filter out such channels in snapshot processing; however, we failed to
filter out bridge related messages that involved these channels.
This patch filters out bridge related messages that are for such channels. This
prevents a spurious WARNING message from being displayed when those channels
move in and out of bridges.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399136 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The masquerade super test is failing on v12 with high fence violations and
crashing. The fence violations are showing that party id allocated memory
strings are somehow getting corrupted in the
bridge_reconfigured_connected_line_update() function. The invalid string
values happen to be the freed memory fill pattern.
After much puzzling, I deduced that the
bridge_reconfigured_connected_line_update() is copying a string out of the
source channel's caller party id struct just as another thread is updating
it with a new value. The copying thread is using the old string pointer
being freed by the updating thread. A search of the code found the
unreal_colp_redirect_indicate() routine updating the caller party id's
without holding the channel lock.
A latent bug in v1.8 and v11 hatched in v12 because of the bridging and
connected line changes. :)
(issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2839/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some long-standing bugs in debug threads that were
exacerbated with recent Optional API work in Asterisk 12.
With debug threads enabled, on some systems, there's a lock ordering
problem between our mutex and glibc's mutex protecting its module list
(Ubuntu Lucid, glibc 2.11.1 in this instance). In one thread, the module
list will be locked before acquiring our mutex. In another thread, our
mutex will be locked before locking the module list (which happens in
the depths of calling backtrace()).
This patch fixes this issue by moving backtrace() calls outside of
critical sections that have the mutex acquired. The bigger change was to
reentrancy tracking for ast_cond_{timed,}wait, which wrongly assumed
that waiting on the mutex was equivalent to a single unlock (it actually
suspends all recursive locks on the mutex).
(closes issue ASTERISK-22455)
Review: https://reviewboard.asterisk.org/r/2824/
........
Merged revisions 398648 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 398649 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added missing unregister of the cdr container in cdr_engine_shutdown().
* Fixed ref leak in off nominal path of cdr_object_alloc().
* Removed some unnecessary NULL checks in cdr_object_dtor().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398562 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed resulting warnings with improper use of ao2_global_obj_replace().
* Made a couple uses of ao2_global_obj_replace_unref(x, NULL) into the
equivalent and more appropriate ao2_global_obj_release() call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When AST_DEVMODE is not defined, ast_asserts are not compiled into the
binary. In some cases, this means variables are not referenced or are
set but unused which causes warnings to show up.
(closes issue ASTERISK-22446)
Reported by: Jason Parker (qwell)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The cleanup code for optional_api needs to happen after all of the optional
API users and providers have unused/unprovided. Unfortunately, regsitering the
atexit() handler at the beginning of main() isn't soon enough, since module
destructors run after that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some configuration objects currently won't place nice if reloaded.
Specifically, in this case the pjsip transport objects. Now when
registering an object in sorcery one may specify that the object is
allowed to be reloaded or not. If the object is set to not reload
then upon reloading of the configuration the objects of that type
will not be reloaded. The initially loaded objects of that type
however will remain.
While the transport objects will not longer be reloaded it is still
possible for a user to configure an endpoint to an invalid transport.
A couple of log messages were added to help diagnose this problem if
it occurs.
(closes issue ASTERISK-22382)
Reported by: Rusty Newton
(closes issue ASTERISK-22384)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2807/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_xmldoc_printable returns an allocated block that must be freed by the
caller. Fixed manager.c and res_agi.c to stop leaking these results.
(closes issue ASTERISK-22395)
Reported by: Corey Farrell
Patches:
manager-leaks-12.patch uploaded by coreyfarrell (license 5909)
res_agi-xmldoc-leaks.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 398060 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 398061 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@398062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Refactored cases where a combination of ast_verbose/options_verbose were
present. Also in general tried to eliminate, in as many places as possible,
where the options_verbose global variable was being used. Refactored the way
local and remote consoles handle verbose message logging in an attempt to
solve the various discrepancies that sometimes would show between the two.
(closes issue AST-1193)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2798/
........
Merged revisions 397948 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made ast_strftime_locale() ensure that the output buffer is initialized.
The std library strftime() returns 0 and does not touch the buffer if it
has an error. However, the function can also return 0 without an error.
(closes issue ASTERISK-22412)
Reported by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed return value of ast_cdr_serialize_variables() on error. It needs
to return 0 indicating no CDR variables found.
* Made ast_cdr_serialize_variables() check the return value of
cdr_object_format_property() and assert if nonzero. A member of the
cdr_readonly_vars[] was not handled.
* Removed unused elements from cdr_readonly_vars[]: total_duration,
total_billsec, first_start, and first_answer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.
There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.
Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.
The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.
Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).
(closes issue ASTERISK-21969)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2754/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Storing a backtrace for each allocation in anticipation of a memory
management problem is very CPU intensive.
* Added the CLI "memory backtrace {on|off}" command to request that the
backtrace be gathered only on request. The backtrace is off by default.
(issue ASTERISK-22221)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel with the OUTGOING flag leaves a bridge, and it will survive
being pulled from the bridge (either because it will execute dialplan,
go into another bridge, or live in a friendly autoloop), we have to clear
the OUTGOING flag. This is the signal to the CDR engine that this channel
is no longer a second class citizen, i.e., it is not "dialed".
The soft hangup flags are only half the picture. If a channel is being
moved from one bridge to another, the soft hangup flags aren't set; however,
the state of the bridge_channel will not be hung up. Since the channel does
not have one of the two hang up states, that implies that the channel is
still technically alive.
This patch modifies the check so that it checks both the soft hangup flags
as well as the bridge_channel state. If either suggests that the channel
is going to persist, we clear the OUTGOING flag.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The config options test requires the entire configuration item to be transparent from
the documentation system. So we let it do that too.
As an aside, please do not use this power for evil. Documentation is your friend, and
you really should document your configurations. Hiding your module's configuration
information from the system attempting to enforce some sanity in the universe is something
only a Bond villain would contemplate.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When originating channels, ast_pbx_outgoing_* caused the dialed channel
reference to be bumped twice. Ostensibly, this routine is bumping the channel
lifetime such that the channel doesn't get nuked in between locks/unlocks;
however, since the routine should return the dialed channel with its
reference bumped, it only needs to do this one time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Michael L. Young
Kevin Harwell
Mark Michelson
Matthew Jordan
Richard Mudgett
David M. Lee
Kinsey Moore
Jonathan Rose
Joshua Colp