[asterisk-dev] invasive fixes to chan_iax2 in 1.4

Loic Didelot ldidelot at voipgate.com
Mon Aug 20 05:13:33 CDT 2007

I will test the version the best I can.

Maybe I have found already something which might need confirmation. I
flood asterisk with iax registration around 100 per second for 7 seconds
and I put it in a loop and let it run for hours.

I monitor the openfiles with lsof and nothing special happens. But an
"iax2 show channels" shows some strange information. The number of
channels is growing and growing. 

After one hour I have 16286 active IAX channels. This makes a reload
impossible or it take a huge amount of time. the "iax2 show netstats"
output is also huge and show the same number of channels.

The good news is that I have had no crash so far.

Russel if you want access to my server just contact me through jabber.

Best regards,
Loic Didelot.

On Fri, 2007-08-17 at 16:20 -0400, Russell Bryant wrote: 
> 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.
voipGATE S.A.
Tel: +352 20 200 223
Fax: +352 20 200 923
E-mail: ldidelot at voipgate.com
Web: http://www.voipgate.com

More information about the asterisk-dev mailing list