Stasis: address refcount races; implementation comments
authorDavid M. Lee <dlee@digium.com>
Fri, 16 Aug 2013 16:03:34 +0000 (16:03 +0000)
committerDavid M. Lee <dlee@digium.com>
Fri, 16 Aug 2013 16:03:34 +0000 (16:03 +0000)
commitf29d969a7969b1122b5039747550c1cb039abd23
tree1a58f7d5b3da514304442e9e596c22008a66c62e
parenta4ffa9f72b3ae9d26d8b190fd05f4f21c6c3544b
Stasis: address refcount races; implementation comments

Change r395954 reordered some stasis object destruction, which should
have been fine. Unfortunately, it caused some hard to reproduce issues
related to objects being accessed after they had been destroyed. The
patch in r396329 fixed the destruction order problem; this patch
addresses the underlying issue. A few other stasis-related fixes were
also added.

 * Add ref-bumps around areas where objects may get transitively
   destroyed. (For example, where we lock a topic, unref a subscription,
   which unrefs the topic, which explodes the topic when we try to
   unlock it.)

 * Wrote an extensive doxygen page about Stasis implementation,
   relationships between objects, lifecycles of objects, how the
   refcounting works, etc. Many other comments were added, corrected, or
   cleaned up.

 * Added an assert to the topic dtor to catch extra ref decrements.

 * Fixed type used after destruction errors for graceful shutdown in
   stasis_channels.c.

 * I added two unit tests in an attempt to catch destruction order
   issues. Since the underlying cause is a race condition, though, the
   tests rarely failed even when the code was wrong.

 * Fixed a leak in stasis_cache_pattern.c.

(closes issue ASTERISK-22243)
Review: https://reviewboard.asterisk.org/r/2746/

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
include/asterisk/astobj2.h
main/stasis.c
main/stasis_cache.c
main/stasis_cache_pattern.c
main/stasis_channels.c
tests/test_stasis.c