[asterisk-dev] invasive fixes to chan_iax2 in 1.4

Russell Bryant russell at digium.com
Fri Aug 17 15:20:03 CDT 2007


Greetings,

I have a branch where I have fixed some bugs in chan_iax2.  The code is intended
to go in both 1.4 and trunk.  The changes are rather invasive, so I wanted to
describe the changes and justify them before merging them in.

svn diff http://svn.digium.com/svn/asterisk/branches/1.4/channels/chan_iax2.c
http://svn.digium.com/svn/asterisk/team/russell/iax_refcount/channels/chan_iax2.c

This branch is targeted at fixing a set of crashes.  They were brought to my
immediate attention by being given access to a system that could be easily
crashed by issuing a reload while running a registration load test.

The problems turned out to be related to the handling of iax2_peer objects.
However, the handling of iax2_user objects suffers from the same problems so the
same changes have been made to them, as well.  There are various situations
where peers could get destroyed while other threads still hold references to them.

To fix this problem, I made it so the objects are reference counted.  To do
this, I had 3 choices.

1) Don't use any object model.  Just write it in "manually".  This felt like the
worst choice.  It's best to use a common implementation when possible.

2) Use astobj.h.  This hasn't made it very far throughout the code base.  The
API is a set of macros which are cumbersome to use, and especially to debug, in
my opinion.  However, it's certainly better than option #1, as it is a common
implementation already in use in some places.  However, it is likely that this
is going to be deprecated in favor of astobj2.

3) Use astobj2.  Luigi Rizzo and one of his students, Marta Carbone, have
written a new reference counted object model and have had it in a branch for a
long time now.  After reviewing astobj versus astobj2, I perferred astobj2, and
decided to go with that.  It doesn't use macros, and is still more efficient.

Another reason that I chose to go with astobj2 was that I *know* this is not the
end of problems of this type.  In fact, there is a nice set of crashes on the
bug tracker which the fix will be converting the ast_channel struct over to a
reference counted object model, which is going to be a big job.  Since we are
likely going to have to do more conversions of object handling to this method, I
figured it was worth bringing in astobj2 to 1.4 so that we can use it as needed,
and not do all of this work using a model that we know will be deprecated in the
near future.

If you have any comments or objections, I would like to hear them.  Also, feel
free to ask for any clarification or more detailed explanations of the things I
have mentioned here.

If there are no objections, I will be merging these changes into 1.4 next week.

-- 
Russell Bryant
Software Engineer
Digium, Inc.



More information about the asterisk-dev mailing list