[asterisk-bugs] [JIRA] (ASTERISK-24477) asterisk segfault in codec_siren7.so

Rusty Newton (JIRA) noreply at issues.asterisk.org
Thu Nov 20 17:37:29 CST 2014


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

Rusty Newton commented on ASTERISK-24477:
-----------------------------------------

{quote}
Yes, I could. Is there a way to share this only with Digium staff? These files are somewhat sensitive, as they contain hundreds of SIP extensions, real usernames, etc. I checked the different groups in Jira that I can chose from when uploading the file, but none of those seem to be sufficiently restrictive. Please let me know how I can make this available without the whole world to see it.
{quote}

We can lock the issue down to only Digium, Bug Marshals and the Reporter, but then that would hide it from all others.. which we don't really want to do unless we really have to. That case would typically be with a security vulnerability.

{quote}
Also, I wonder what the relevance of sip.conf and dialplan is in this crash. It is quite clearly codec-related, and I would believe that it might has to do with multi-threaded use of the codec, a race condition of some sort, or transcoding that fails...
{quote}

sip.conf and dialplan would be useful for reproduction and understanding how the system got to where it is at during the crash. If you think we are unlikely to reproduce the issue then lets forget about that for the moment.

[~mmichelson] looked at the traces for us and it turns out we may be able to further investigate the issue with only the traces. However. what may also help is an Asterisk log showing what is happening up to the crash. Can you provide a log, including the output of "sip set debug on" and the DEBUG type logger channel? You can find some specific instructions on the wiki: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information.

Once you have that log, it should be trivial for you to scrub out all IP addresses if necessary. If it comes down to it, then we can probably lock down the issue.

> asterisk segfault in codec_siren7.so
> ------------------------------------
>
>                 Key: ASTERISK-24477
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24477
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Codecs/codec_siren7
>    Affects Versions: 11.13.0
>         Environment: Debian 3.2.63-2 i686 GNU/Linux
> Asterisk 11.13.0~dfsg-1~bpo70+1
> Digium Siren7 Module Version 11.0_1.0.5 (optimized for i686_32)
>            Reporter: Daniel Ammann
>            Assignee: Daniel Ammann
>         Attachments: backtrace1.txt, backtrace2.txt, backtrace3.txt, backtrace.txt
>
>
> Using Siren7 codec throws a segfault at random times during a call. THe Endpoints involved are different Polycom IP6000 and IP7000 phones
> Segfault
> {noformat}
> kernel: [754930.655998] asterisk[22492]: segfault at b63ff000 ip b5d336a9 sp b1948610 error 4 in codec_siren7.so[b5d2f000+f000]
> kernel: [827976.561636] asterisk[2558]: segfault at b1e00000 ip b64386a9 sp b16ba610 error 4 in codec_siren7.so[b6434000+f000]
> kernel: [927814.320410] asterisk[27330]: segfault at b0b00000 ip b61086a9 sp af2a0610 error 4 in codec_siren7.so[b6104000+f000]
> {noformat}
> At the time of the crash, several Polycom endpoints were using this asterisk instance with siren7 codec in parallel. The typical usage scenario is that those endpoints are participating on app_conference based conferencing, and transcoding is happening for those endpoints (siren7 -> slin16)
> This problems occurs in guesstimated 1 out of 20 calls, and minutes to hours after the call has been established
> I can make core dumps available if helpful



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



More information about the asterisk-bugs mailing list