[asterisk-dev] [Code Review]: Make ast_unload_resource actually remove the module from the module list when it is unloaded

Tilghman Lesher reviewboard at asterisk.org
Tue Feb 21 03:48:55 CST 2012



> On Feb. 20, 2012, 2:33 p.m., Mark Michelson wrote:
> > I think a better idea is to call both ast_unload_resource() and ast_module_unregister() in res_calendar.c.
> 
> Terry Wilson wrote:
>     I'd have to pass around pointers to the ast_module_info instead of just using AST_MODULE. The weird thing is that 1.8 doesn't seem to have the problem at all. Something has changed between there and trunk that is screwing things up.

The module shutdown routine has a loop that permits dependency ordering, if the usecount is set greater than zero.  It may be helpful to increment the usecount of res_calendar for each dependent module registered.  That would allow you to delay the unload of res_calendar until after all dependent modules are unloaded.  There's no good way of doing this currently, however, as usecount is defined within loader.c, and it is not accessible without providing a channel for sending a softhangup to at the appropriate moment.


- Tilghman


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


On Feb. 18, 2012, 1:31 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1752/
> -----------------------------------------------------------
> 
> (Updated Feb. 18, 2012, 1:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> res_calendar calls ast_unload_resource for the related tech modules when it is unloaded. If this happens through a 'core stop gracefully', then it will be unloading the tech modules that are already in the list that is being traversed (supposedly safely) for unloading, eventually causing a double free. The problem seems to be that ast_unload_resource, while it calls the unload() callback function for the module, does not actually unlink the module from the list of modules. So the AST_LIST_TRAVERSE_SAFE_BEGIN {} still iterates over the unloaded module.
> 
> This patch causes ast_unload_resource to call AST_LIST_REMOVE on successfully unloaded modules.
> 
> 
> Diffs
> -----
> 
>   /trunk/main/loader.c 355783 
> 
> Diff: https://reviewboard.asterisk.org/r/1752/diff
> 
> 
> Testing
> -------
> 
> Scenario: Start Asterisk with res_calendar and assorted calendar tech modules loaded. Run 'core stop gracefully'.
> Before patch: Crash.
> After patch: No crash.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120221/5ff9bd54/attachment.htm>


More information about the asterisk-dev mailing list