Skip to content
Snippets Groups Projects
  1. Jun 03, 2013
    • David M. Lee's avatar
      Correct autoconf script for finding UUID support. · 6d805dc0
      David M. Lee authored
      The library that provides UUID support varies greatly from system to
      system. On most Linux distros, it's in libuuid. On OpenBSD, it's in
      libe2fs-uuid. On OS X, it is in libsystem.
      
      This patch plays hide-and-seek with UUID support, looking for it in the
      three places we know about. It also corrects the Makefile so that it uses
      the configured library name and include path.
      
      (closes issue ASTERISK-21816)
      Reported by: Brad Latus (snuffy)
      Tested by: Brad Latus (snuffy)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      6d805dc0
  2. May 31, 2013
  3. May 30, 2013
    • David M. Lee's avatar
      Missed a line from a bad merge in r390122 · 721a1faf
      David M. Lee authored
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      721a1faf
    • David M. Lee's avatar
      Avoid unnecessary cleanups during immediate shutdown · d81c8467
      David M. Lee authored
      This patch addresses issues during immediate shutdowns, where modules
      are not unloaded, but Asterisk atexit handlers are run.
      
      In the typical case, this usually isn't a big deal. But the
      introduction of the Stasis message bus makes it much more likely for
      asynchronous activity to be happening off in some thread during
      shutdown.
      
      During an immediate shutdown, Asterisk skips unloading modules. But
      while it is processing the atexit handlers, there is a window of time
      where some of the core message types have been cleaned up, but the
      message bus is still running. Specifically, it's still running
      module subscriptions that might be using the core message types. If a
      message is received by that subscription in that window, it will
      attempt to use a message type that has been cleaned up.
      
      To solve this problem, this patch introduces ast_register_cleanup().
      This function operates identically to ast_register_atexit(), except
      that cleanup calls are not invoked on an immediate shutdown. All of
      the core message type and topic cleanup was moved from atexit handlers
      to cleanup handlers.
      
      This ensures that core type and topic cleanup only happens if the
      modules that used them are first unloaded.
      
      This patch also changes the ast_assert() when accessing a cleaned up
      or uninitialized message type to an error log message. Message type
      functions are actually NULL safe across the board, so the assert was a
      bit heavy handed. Especially for anyone with DO_CRASH enabled.
      
      Review: https://reviewboard.asterisk.org/r/2562/
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      d81c8467
  4. May 29, 2013
  5. May 28, 2013
  6. May 27, 2013
    • Matthew Jordan's avatar
      Fix some more fax test errors due to needing the peer in a bridge · 2d2a47fa
      Matthew Jordan authored
      In r389799, a number of fax errors in gateway mode were fixed by using the
      appropriate function to get a channel's peer while in a bridge. This patch
      does two things:
      (1) It uses the same function in res_fax_spandsp while starting the fax
          gateway. Without this, the fax gateway will not actually start up, as
          res_fax_spandsp also must inspect the channel's peer in a two-party
          bridge
      (2) It refactors some ao2 objects in sendfax_exec to use RAII_VAR. This was
          reverted in r389799 as some off nominal paths were getting hit without
          the fix in (1) that indicated an ao2 object issue; this turned out to
          be a red herring (which is an odd phrase)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      2d2a47fa
    • Matthew Jordan's avatar
      Initialize the message type before the topic · a0f6d184
      Matthew Jordan authored
      Caching topics will during initialization attempt to reference
      their message type. The message type therefore has to be
      initialized prior to the topic to prevent the dreaded assertion.
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      a0f6d184
  7. May 26, 2013
    • Matthew Jordan's avatar
      Fix a few fax gateway failures · 9e350966
      Matthew Jordan authored
      Fax gateway requires knowledge of a channel's peer in a bridge. This patch
      now uses the supported mechanisms to get this information.
      
      This is acceptable for a few reasons:
      * Fax gateway can only ever work in a 2-party bridge
      * Fax gateway cannot work when not in a bridge
      * Fax gateway cannot work without knowledge of the capabilities of both
        channels in the fax operation (it is, after all, a gateway)
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      9e350966
    • Matthew Jordan's avatar
      Fix a variety of memory corruption/assertion errors · fe3ca540
      Matthew Jordan authored
      * Initialize a Stasis-Core message type prior to initializing a caching topic.
        The caching topic will attempt to use the message type.
      * Don't attempt to publish Stasis-Core messages from remote console connections.
        They aren't the main process; they shouldn't attempt to behave as it (they also
        don't have the infrastructure to do so)
      * Don't treat a JSON object as an ao2 object (whoops)
      * In asterisk.c, ref bump the JSON even package that is distributed with the
        event meta data. The callers assume that they own the reference, and the packing
        routine steals references.
      
      
      git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      fe3ca540
  8. May 25, 2013
  9. May 24, 2013
  10. May 23, 2013
Loading