[asterisk-bugs] [JIRA] (ASTERISK-24875) Randomly get segfaults processing WEBRTC calls

[Jacques Brooks (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Brooks updated ASTERISK-24875:
--------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

I turned on the required logging but after waiting a couple of hours I shut off the logging when I hadn't received the segfault yet and the log size was close to 8G.  I noticed that at some point I start to get the message "astobj2.c: bad magic number for object 0xfa5910. Object is likely destroyed" spewing out at close to 6,000 times a second. I'm wondering if perhaps this already indicates that the underlying problem has kicked in that will eventually cause the segfault and if maybe I can shut off logging at that point and submit the log or do I need to wait for the segfault to occur?

> Randomly get segfaults processing WEBRTC calls
> ----------------------------------------------
>
>                 Key: ASTERISK-24875
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24875
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.16.0, 13.2.0
>         Environment: CentOS Linux
>            Reporter: Jacques Brooks
>            Assignee: Jacques Brooks
>            Severity: Critical
>         Attachments: backtrace.txt
>
>
> Asterisk randomly crashes when processing WEBRTC calls. Doesn't seem to be dependent on number of calls currently handling or how long Asterisk is running; have crashed with less than 10 calls and over 200 calls and have crashed with Asterisk running less than 20 minutes and at times when it's been running for hours  Using version 13.2 with sip.conf.  Tried to convert to pjsip.conf but was not very successful (would get only one or two calls up before crashing) so reverted back to sip.conf. 



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