[asterisk-bugs] [JIRA] (ASTERISK-21775) FPE during MOH playback

Walter Doekes (JIRA) noreply at issues.asterisk.org
Wed May 28 08:27:45 CDT 2014


    [ https://issues.asterisk.org/jira/browse/ASTERISK-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218536#comment-218536 ] 

Walter Doekes commented on ASTERISK-21775:
------------------------------------------

This is the same problem as ASTERISK-22083, look at {{class=0x2b9ae0071268}}

In both threads, that {{class}} is used and moh_scan_files is destructive.

{noformat}
Thread 2 (Thread 26748):
#0  0x0000003baa6c7b97 in chdir () from /lib64/libc.so.6
#1  0x00002b9ac0a73283 in moh_scan_files (class=0x2b9ae0071268) at res_musiconhold.c:1074
#2  0x00002b9ac0a74dae in local_ast_moh_start (chan=0x2b9abc15d558, mclass=0x2b9ad9bc3eb0 "default", interpclass=0x0) at res_musiconhold.c:1516

Thread 1 (Thread 0x2b9adacf5940 (LWP 26746)):
#0  0x00002b9ac0a708e0 in moh_files_alloc (chan=0x2b9ae0071fc8, params=0x2b9ae0071268) at res_musiconhold.c:432
#1  0x000000000046eef1 in ast_activate_generator (chan=0x2b9ae0071fc8, gen=0x2b9ac0c789c0, params=0x2b9ae0071268) at channel.c:3150
#2  0x00002b9ac0a74ebe in local_ast_moh_start (chan=0x2b9ae0071fc8, mclass=0x2b9adaceeeb0 "default", interpclass=0x0) at res_musiconhold.c:1533
{noformat}

As soon as someone schedules a reload, things "might" break. In the other ticket, it happens more frequently, but the cause is the same: there is no locking of the class->stuff and they're free to be mutated by moh_scan_files. The free loop there runs for a longer time than the modulo here, but other than that, no difference.

In https://issues.asterisk.org/jira/secure/attachment/49162/backtrace-220113.txt 10 bucks says that {{state->class}} in {{state->pos %= state->class->total_files;}} is the same class as {{moh_scan_files (class=0x3b483c8)}}.

The only times moh_scan_files() is called (apart from alloc/init time) is when either using cachertclasses=yes or issuing a 'module reload res_musiconhold' or a 'moh reload'.

The fix, I think (other than adding loads of locking):
- (re)scan_files would have to build a new object, and replace that. and the others should decref the old one until it goes to zero and can be freed.
- combine that with fewer calls to moh_scan_files for realtime (why reload if it was just reloaded?)



> FPE during MOH playback
> -----------------------
>
>                 Key: ASTERISK-21775
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21775
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_musiconhold
>    Affects Versions: 1.8.21.0
>         Environment: Linux pbx 2.6.18-348.1.1.el5 #1 SMP Tue Jan 22 16:19:19 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: James Sharp
>            Assignee: Michael L. Young
>         Attachments: asterisk-21775-lock-class_1.8.diff, asterisk-21775-ref-mohclass_1.8.diff, asterisk-bt-11-4.txt, backtrace-211213.txt, backtrace-220113.txt, backtrace-26Aug.txt, backtrace.txt
>
>
> Asterisk has dropped several calls and triage found core files in the MOH directory.  I will attach the backtrace and diagnostics.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list