Commit Graph

13 Commits

Author SHA1 Message Date
Richard Mudgett 40d19f2e55 logging,cdr,cel: Fix stringfield memory leak.
The stringfields refactor to allow adding stringfields to the end of a
structure (f6f4cf459f) exposed some
incomplete cleanup code by some stringfield users.

The most noticeable leaker is the logging system where there is a leak for
every log message generated.

ASTERISK-26078 #close
Reported by:  Etienne Lessard
Patches:
      jira_asterisk_26078_v13.patch (license #5621) patch uploaded
      by Richard Mudgett

Change-Id: If6a08b31336b492c3de6f9dfd07c447f8d5a8782
2016-06-01 14:09:36 -05:00
Matt Jordan 4a58261694 git migration: Refactor the ASTERISK_FILE_VERSION macro
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
2015-04-13 03:48:57 -04:00
Mark Michelson dcf1ad14da Add module support level to ast_module_info structure. Print it in CLI "module show" .
ASTERISK-23919 #close
Reported by Malcolm Davenport

Review: https://reviewboard.asterisk.org/r/3802



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-25 16:47:17 +00:00
Matthew Jordan 3713fa5c9f Prevent CDR backends from unregistering while billing data is in flight
This patch makes it so that CDR backends cannot be unregistered while active
CDR records exist. This helps to prevent billing data from being lost during
restarts and shutdowns.

Review: https://reviewboard.asterisk.org/r/2880/
........

Merged revisions 402081 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-27 20:04:17 +00:00
Matthew Jordan 6258bbe7bd Update Asterisk's CDRs for the new bridging framework
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
2013-06-17 03:00:38 +00:00
Andrew Latham 02bcd5bfb6 Doxygen Updates - Title update
Update and extend the configuration_file group and enable linking.  Update title that was left behind many years ago.

(issue ASTERISK-20259)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-10-14 21:46:45 +00:00
Terry Wilson 57f42bd74f ast_channel opaquification of pointers and integral types
Review: https://reviewboard.asterisk.org/r/1753/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2012-02-20 23:43:27 +00:00
Richard Mudgett 55b70ae625 Merged revisions 337974 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10

................
  r337974 | rmudgett | 2011-09-26 14:35:23 -0500 (Mon, 26 Sep 2011) | 37 lines
  
  Merged revisions 337973 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r337973 | rmudgett | 2011-09-26 14:30:39 -0500 (Mon, 26 Sep 2011) | 30 lines
    
    Fix deadlock when using dummy channels.
    
    Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
    ast_channel_unref().  Using ast_channel_release() needlessly grabs the
    channel container lock and can cause a deadlock as a result.
    
    * Analyzed use of ast_dummy_channel_alloc() and made use
    ast_channel_unref() when done with the dummy channel.  (Primary reason for
    the reported deadlock.)
    
    * Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
    locks.  Chan_local could not perform deadlock avoidance correctly.
    (Potential deadlock exposed by this issue.  Secondary reason for the
    reported deadlock since the held lock was part of the deadlock chain.)
    
    * Fixed some uses of ast_dummy_channel_alloc() not checking the returned
    channel pointer for failure.
    
    * Fixed some potential chan=NULL pointer usage in func_odbc.c.  Protected
    by testing the bogus_chan value.
    
    * Fixed needlessly clearing a 1024 char auto array when setting the first
    char to zero is enough in manager.c:action_getvar().
    
    (closes issue ASTERISK-18613)
    Reported by: Thomas Arimont
    Patches:
          jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
    Tested by: Thomas Arimont
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-09-26 19:40:12 +00:00
Leif Madsen a525edea59 Merged revisions 328247 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.10

................
  r328247 | lmadsen | 2011-07-14 16:25:31 -0400 (Thu, 14 Jul 2011) | 14 lines
  
  Merged revisions 328209 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r328209 | lmadsen | 2011-07-14 16:13:06 -0400 (Thu, 14 Jul 2011) | 6 lines
    
    Introduce <support_level> tags in MODULEINFO.
    This change introduces MODULEINFO into many modules in Asterisk in order to show
    the community support level for those modules. This is used by changes committed
    to menuselect by Russell Bryant recently (r917 in menuselect). More information about
    the support level types and what they mean is available on the wiki at
    https://wiki.asterisk.org/wiki/display/AST/Asterisk+Module+Support+States
  ........
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@328259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-07-14 20:28:54 +00:00
Russell Bryant 15b8740f80 Merged revisions 317480 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r317480 | russell | 2011-05-05 18:00:55 -0500 (Thu, 05 May 2011) | 8 lines
  
  Don't lose cdr_syslog config on a reload.
  
  (closes issue #18679)
  Reported by: enegaard
  Patches:
        issue18679_seanbright.patch uploaded by seanbright (license 71)
  Tested by: enegaard
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317481 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-05-05 23:02:11 +00:00
Tilghman Lesher b4e18d5660 Add load priority order, such that preload becomes unnecessary in most cases
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-20 19:35:02 +00:00
Russell Bryant a297f2d04e formatting tweaks and constification
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-02-26 08:45:11 +00:00
Sean Bright a4284a507b Add a new module, cdr_syslog, which allows writing CDRs to syslog.
The original patch for this was written by Brett Bryant, and I split it out into
it's own module.

(closes issue #12876)
Reported by: bbryant
Patches:
      06162008_cdr_custom_syslog.diff uploaded by bbryant (license 36)
      05212009_cdr_syslog.patch uploaded by seanbright (license 71)
Tested by: seanbright

Review: https://reviewboard.asterisk.org/r/297/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-06-26 22:08:05 +00:00