[asterisk-dev] [Code Review] 3282: Fix a refcount error with realtime MOH

[Russell Bryant]

> On March 3, 2014, 3:30 p.m., Michael Young wrote:
> > ASTERISK-21775 is still open that had this same fix in it because the testers were still reporting a problem.  Is the crash similar to what the reporters on that issue have been reporting?
> > 
> > Thanks

The crash I saw is different


- Russell


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


On March 2, 2014, 8:45 p.m., Russell Bryant wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3282/
> -----------------------------------------------------------
> 
> (Updated March 2, 2014, 8:45 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> I observed a crash in res_musiconhold on an Asterisk 11 system using realtime MOH.  Investigation of the backtrace showed a corrupt mohclass, implying that it got destroyed before the code expected it to.  I went looking for reference counting errors that could have caused this crash and this patch this result.  It contains 2 changes.
> 
> 1) Remove a usless block of code that was impossible to reach.  There was even a comment indicating that it was impossible to reach.  The conditional includes "!ast_test_flag(global_flags, MOH_CACHERTCLASSES)" and it's inside of an if block with the opposite check "ast_test_flag(global_flags, MOH_CACHERTCLASSES)".  There's no good reason to keep it around.
> 
> 2) A similar block to #1 contained a reference counting error.  It stores state->class in the local variable mohclass without increasing its reference count.  The reference count on mohclass is decremented at the end of the function.  This block of code probably very rarely runs, which would help explain why this system was working fine for many months before experiencing a crash.
> 
> 
> Diffs
> -----
> 
>   /branches/11/res/res_musiconhold.c 409286 
> 
> Diff: https://reviewboard.asterisk.org/r/3282/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Russell Bryant
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140303/3d16a447/attachment.html>