[asterisk-bugs] [JIRA] (ASTERISK-26692) res_rtp_asterisk: Crash in dtls_srtp_handle_timeout at res_rtp_asterisk (using chan_sip)

[Rusty Newton (JIRA)]

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

Rusty Newton updated ASTERISK-26692:
------------------------------------

    Assignee: scgm11  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Thanks for the additional trace, however you still didn't provide the debug log as requested. 

In this case the trace isn't enough, developers can't tell how it got into the funky state that resulted in the crash.

Please reference my previous comments for instructions on gathering a debug log leading up to the crash. As it right now, we don't have enough data for a developer to investigate so I would be hesistant to open the issue up.

> res_rtp_asterisk: Crash in dtls_srtp_handle_timeout at res_rtp_asterisk (using chan_sip)
> ----------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26692
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26692
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Resources/res_rtp_asterisk
>    Affects Versions: 13.13.0
>         Environment: Ubuntu 16.04
>            Reporter: scgm11
>            Assignee: scgm11
>         Attachments: backtracefull.txt, backtrace.txt, backtrace.txt, dump1.txt, logbeforedump.txt, logtimeofbt.txt
>
>
> Only dumps occasionally:
> {noformat}
> #0  dtls_srtp_handle_timeout (instance=instance at entry=0x7fc860007180, rtcp=rtcp at entry=1) at res_rtp_asterisk.c:1910
>         rtp = 0x7fc86001c220
>         dtls = 0x240
>         dtls_timeout = {tv_sec = 140498581643312, tv_usec = 140498715030608}
> #1  0x00007fc838bd5823 in dtls_srtp_handle_rtcp_timeout (data=0x7fc860007180) at res_rtp_asterisk.c:1941
>         instance = 0x7fc860007180
>         reschedule = <optimized out>
> #2  0x00000000005b00fb in ast_sched_runq (con=0x24a53f0) at sched.c:783
>         current = 0x24b5140
>         numevents = 11
>         res = <optimized out>
>         __PRETTY_FUNCTION__ = "ast_sched_runq"
> #3  0x00007fc8312e28ee in do_monitor (data=data at entry=0x0) at chan_sip.c:29502
>         res = <optimized out>
>         t = 1483976610
>         reloading = <optimized out>
>         __PRETTY_FUNCTION__ = "do_monitor"
> {noformat}
> dmesg:
> {noformat}
> [6126811.297251] asterisk[21118]: segfault at 278 ip 00007fad67faa822 sp 00007fad62bb6ce0 error 4 in res_rtp_asterisk.so[7fad67f9f000+1a000]
> [5438520.048513] asterisk[17423]: segfault at 278 ip 00007f8d3b777772 sp 00007f8d363ffce0 error 4 in res_rtp_asterisk.so[7f8d3b76c000+1a000]
> [5003538.737797] asterisk[28892]: segfault at 278 ip 00007fc3757f8772 sp 00007fc37030cce0 error 4 in res_rtp_asterisk.so[7fc3757ed000+1a000]
> {noformat}
> in messages I can see this that is the only thing that could be the issue:
> {noformat}
> [Jan  4 10:08:21] WARNING[29724][C-00000f32] chan_sip.c: Insufficient information for SDP (m= not found)
> {noformat}
> may be related to ASTERISK-9041 ?



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