[asterisk-bugs] [JIRA] (ASTERISK-27534) chan_sip: Assumes iostream is non-NULL when it may not be

[Ludovic Gasc (Eyepea) (JIRA)]

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

Ludovic Gasc (Eyepea) commented on ASTERISK-27534:
--------------------------------------------------

Hi,

I'm not the reporter, however we are testing 15.2-rc2 on three servers, and we have seen also this stacktrace with the more or less the same frequency.

We have applied this patch two days ago, we don't have anymore crashes since the deployment.

No side effects observed for now.

> chan_sip: Assumes iostream is non-NULL when it may not be
> ---------------------------------------------------------
>
>                 Key: ASTERISK-27534
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27534
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General, Core/General
>    Affects Versions: 15.1.4
>            Reporter: Lubos Dolezel
>            Assignee: Unassigned
>              Labels: patch
>         Attachments: ASTERISK-27534.diff
>
>
> I'd like to report a crash, this is the backtrace based on the coredump:
> {code}
> #0  ast_iostream_get_fd (stream=0x0) at iostream.c:75
> #1  0x00007f32d32355d4 in sip_prepare_socket (p=0x7f325c057598) at chan_sip.c:29239
> #2  __sip_xmit (p=0x7f325c057598, data=0x7f325c010210) at chan_sip.c:3753
> #3  0x00007f32d323600d in __sip_reliable_xmit (p=p at entry=0x7f325c057598, seqno=seqno at entry=102, resp=resp at entry=0, data=<optimized out>, fatal=fatal at entry=1, sipmethod=<optimized out>) at chan_sip.c:4267
> #4  0x00007f32d323c1c9 in send_request (p=0x7f325c057598, req=0x7f32ba8be040, reliable=XMIT_CRITICAL, seqno=102) at chan_sip.c:4816
> #5  0x00007f32d3255220 in transmit_invite (p=p at entry=0x7f325c057598, sipmethod=sipmethod at entry=3, sdp=sdp at entry=0, init=init at entry=2, explicit_uri=explicit_uri at entry=0x0) at chan_sip.c:14801
> #6  0x00007f32d325eb98 in sip_poke_peer (peer=peer at entry=0x2e8ff58, force=force at entry=0) at chan_sip.c:30300
> #7  0x00007f32d325f295 in sip_poke_peer_s (data=0x2e8ff58) at chan_sip.c:16587
> #8  0x00000000005cff9f in ast_sched_runq (con=0x2e5da40) at sched.c:781
> #9  0x00007f32d3278e75 in do_monitor (data=data at entry=0x0) at chan_sip.c:29709
> #10 0x00000000006186dd in dummy_start (data=<optimized out>) at utils.c:1257
> #11 0x00007f338f70e73a in start_thread () from /lib64/libpthread.so.0
> #12 0x00007f338ebef85f in clone () from /lib64/libc.so.6
> {code}
> Asterisk would crash every ~1 hour or so. At this point, it is sending out an OPTIONS packet to a {{host=dynamic}} SIP peer that has {{qualify}} enabled and frequently goes offline. The peer uses TLS.
> {code}
> (gdb) f 1
> #1  0x00007f32d32355d4 in sip_prepare_socket (p=0x7f325c057598) at chan_sip.c:29239
> 29239                   return ast_iostream_get_fd(s->tcptls_session->stream);
> (gdb) p s->tcptls_session
> $3 = (struct ast_tcptls_session_instance *) 0x7f3268000b98
> (gdb) p s->tcptls_session->stream
> $4 = (struct ast_iostream *) 0x0
> {code}
> Turning {{qualify}} off for this peer fixed the problem.



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