[asterisk-dev] [Code Review] Resolve some cleanup issues during module unload of chan_iax2

[Russell Bryant]

> On 2010-06-23 15:07:05, David Vossel wrote:
> > /trunk/channels/chan_iax2.c, lines 13896-13901
> > <https://reviewboard.asterisk.org/r/736/diff/1/?file=11003#file11003line13896>
> >
> >     Do the pvt's and their locks have to be destroyed in separate loops?! That's a crazy amount of iterating.

Probably not, but I'm not sure off of the top of my head if a call on one call number would ever try to lock a different call number.  If so, then it needs to stay this way.


- Russell


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/736/#review2256
-----------------------------------------------------------


On 2010-06-22 17:50:39, Russell Bryant wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/736/
> -----------------------------------------------------------
> 
> (Updated 2010-06-22 17:50:39)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> The external test suite stops Asterisk using the "core stop gracefully" command.  The logs from the tests show that there are a number of problems with Asterisk trying to cleanly shut down.  This patch addresses the following type of error that comes from chan_iax2:
> 
> [Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy: chan_iax2.c line 11371 (iax2_process_thread_cleanup): Error destroying mutex &thread->lock: Device or resource busy
> 
> For an example in the context of a build, see:
> 
> http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
> 
> The primary purpose of this patch is to change the thread pool shutdown procedure to be more explicit to ensure that the thread exits from a point where it is not holding a lock.  While testing that, I encountered various crashes due to the order of operations in unload_module() being problematic.  I reordered some things there, as well.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_iax2.c 272048 
> 
> Diff: https://reviewboard.asterisk.org/r/736/diff
> 
> 
> Testing
> -------
> 
> I have started and stopped Asterisk using "core stop gracefully" many times and ensured that no errors were produced by chan_iax2.  I also ran the same process under valgrind a few times and ensured that it did not report any problems.
> 
> 
> Thanks,
> 
> Russell
> 
>