Review Board 1.7.16


Stasis: address refcount races; implementation comments

Review Request #2746 - Created Aug. 7, 2013 and submitted

David Lee
/trunk
ASTERISK-22243
Reviewers
asterisk-dev
mjordan
Asterisk
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.
Unit tests pass.

Reverted r396329, ran unit tests and scenarios that seemed to aggravate the race
condition without error.
Total:
2
Open:
0
Resolved:
2
Dropped:
0
Status:
From:
Review request changed
Updated (Aug. 16, 2013, 11:20 a.m.)
  • changed from pending to submitted
Committed in revision 396848

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.