[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:comment-tabpanel&focusedCommentId=235004#comment-235004 ] 

Rusty Newton edited comment on ASTERISK-26692 at 2/2/17 7:23 AM:
-----------------------------------------------------------------

bq. as you can understand is impossible to get debug log for this issue, is random and I cannot reproduce all the time, so getting a debug log makes it impossible....

If the issue is disk space, turn up logging, rotate and delete old logs so they don't get out of control, when Asterisk crashes copy the current log to a new directory.

Now, if the problem is performance issues due to the additional logging then I understand. Not much you can do there unless you can build a clone system and run test traffic on it to simulate and trigger the issue.

bq. so this is a real issue that is why I think this should be remain open, maybe others have the same issue and can share more logs. closing this issue wont make the bug disappear....

We open up and track issues that have enough information for investigation. If we don't have enough data for a developer to investigate then there is no reason to keep it open. In a closed state the issue is still visible and searchable - we can always open it up if someone gathers additional data in the future.

If we kept every issue open then the issue tracker would be filled with issues that never led to any resolution which causes confusion when searching through open issues.

bq. I will try anyway to see if I can have lucky and get some debug logs....

I'll leave this open for a few more weeks. Thanks.


was (Author: rnewton):
bq .as you can understand is impossible to get debug log for this issue, is random and I cannot reproduce all the time, so getting a debug log makes it impossible....

If the issue is disk space, turn up logging, rotate and delete old logs so they don't get out of control, when Asterisk crashes copy the current log to a new directory.

Now, if the problem is performance issues due to the additional logging then I understand. Not much you can do there unless you can build a clone system and run test traffic on it to simulate and trigger the issue.

bq. so this is a real issue that is why I think this should be remain open, maybe others have the same issue and can share more logs. closing this issue wont make the bug disappear....

We open up and track issues that have enough information for investigation. If we don't have enough data for a developer to investigate then there is no reason to keep it open. In a closed state the issue is still visible and searchable - we can always open it up if someone gathers additional data in the future.

If we kept every issue open then the issue tracker would be filled with issues that never led to any resolution which causes confusion when searching through open issues.

bq. I will try anyway to see if I can have lucky and get some debug logs....

I'll leave this open for a few more weeks. Thanks.

> 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)