Asterisk 11.7.0 segfault

Asterisk goes down with segfault randomly.

Error message is the same every time:
[1639257.416689] asterisk[19118]: segfault at 9f0 ip 00000000004906a0 sp 00007f309d4da3f8 error 6 in asterisk[400000+209000]

In most cases last messages in log file prior segfault are:

[Dec 26 15:53:50] WARNING[645][C-000005ac] chan_sip.c: Ignoring audio media offer because port number is zero
[Dec 26 15:53:50] WARNING[645][C-000005ac] chan_sip.c: Failing due to no acceptable offer found

However those two warns appear periodically and no segfault happens.

Please shed a light on it if anyone has any ideas.

Thanks.

wiki.asterisk.org/wiki/display/ … +Backtrace

Backtrace lives here: pastebin.com/zShJnA91

Many thanks!

It’s passing a null channel reference when setting the hangup cause. You will need to raise this as a bug on issues.asterisk.org/jira/

First you will need to obtain debug level 5, verbose level 5 and sip set debug on type output from the call that is causing the crash. Take these from a full log file, which you should enable in logger.conf, not from a screen scrape. The backtrace and the the logs should be attached to the bug report, not linked from it and not embedded, although you can include a very small number of key lines in the report itself…

It looks like the original cause may be a protocol violation or maybe the SIP device is starting a call in the held state, using the deprecated way of doing SIP holds. I don’t know if that allows you to work out an avoidance tactic.

#0  0x00000000004984ff in ast_channel_hangupcause_set (chan=0x0, value=58) at channel_internal_api.c:580
No locals.
#1  0x00007ff17ca7417b in handle_response_invite (p=0x7ff0b81d2f98, resp=200, rest=0x7ff1380b89d4 "OK", req=0x7ff1788ee2a0, seqno=102) at chan_sip.c:22821
        outgoing = 1
        res = -1
        xmitres = 0
        reinvite = 0
        p_hdrval = 0x7ff1788edbc0 "\001"
        rtn = 32753
        connected = {id = {name = {str = 0x0, char_set = 0, presentation = 0, valid = 0 '\000'}, number = {str = 0x0, plan = 0, presentation = 0, valid = 0 '\000'}, subaddress = {
              str = 0x0, type = 0, odd_even_indicator = 0 '\000', valid = 0 '\000'}, tag = 0x0}, ani = {name = {str = 0x0, char_set = 0, presentation = 0, valid = 0 '\000'}, number = {
              str = 0x0, plan = 0, presentation = 0, valid = 0 '\000'}, subaddress = {str = 0x0, type = 2022628944, odd_even_indicator = 241 '\361', valid = 127 '\177'},
            tag = 0x7ff1c644c0ac "A\200\375SD\213\235\250\374\377\377D\213\205\260\374\377\377H\213\215\270\374\377\377\017\207\033\377\377\377H\215\005\202\373\021"}, priv = {name = {
              str = 0x0, char_set = 0, presentation = 0, valid = 255 '\377'}, number = {str = 0x7ff17cad3c01 "n", plan = 0, presentation = 0, valid = 0 '\000'}, subaddress = {
              str = 0x0, type = 0, odd_even_indicator = 0 '\000', valid = 0 '\000'}, tag = 0x0}, ani2 = 0, source = 0}
        update_connected = {id = {name = 0 '\000', number = 0 '\000', subaddress = 0 '\000'}, ani = {name = 0 '\000', number = 255 '\377', subaddress = 255 '\377'}, priv = {
            name = 255 '\377', number = 255 '\377', subaddress = 120 'x'}}
        __PRETTY_FUNCTION__ = "handle_response_invite"
#2  0x00007ff17ca79a2a in handle_response (p=0x7ff0b81d2f98, resp=200, rest=0x7ff1380b89d4 "OK", req=0x7ff1788ee2a0, seqno=102) at chan_sip.c:23820
        owner = 0x0
        sipmethod = 5
        c = 0x7ff1380b8b36 "102 INVITE"
        c_copy = 0x7ff1788edcc0 "102 INVITE"
        msg = 0x7ff1788edcc4 "INVITE"
        __PRETTY_FUNCTION__ = "handle_response"
#3  0x00007ff17ca8d538 in handle_incoming (p=0x7ff0b81d2f98, req=0x7ff1788ee2a0, addr=0x7ff1788eed10, recount=0x7ff1788ee250, nounlock=0x7ff1788ee254) at chan_sip.c:28137
        cmd = 0x7ff1380b89c8 "SIP/2.0"
        cseq = 0x7ff1380b8b36 "102 INVITE"
        useragent = 0x7ff1380b8bdb "3CXPhone 6.0.26523.0"
        via = 0x7ff1380b89dc "SIP/2.0/UDP 178.63.4.162:5060;branch=z9hG4bK4c97c67c;rport=5060"
        callid = 0x7ff1380b8afd "019bd8e1134edc013e2bfad96167381a@178.63.4.162:5060"
        via_pos = 2
        seqno = 102
        len = 4
        respid = 200
        res = 0
        e = 0x7ff1380b89d0 "200 OK"
        error = 0
        oldmethod = 5
        acked = 0
        __PRETTY_FUNCTION__ = "handle_incoming"
#4  0x00007ff17ca8ebe9 in handle_request_do (req=0x7ff1788ee2a0, addr=0x7ff1788eed10) at chan_sip.c:28447
        p = 0x7ff0b81d2f98
        owner_chan_ref = 0x0
        recount = 0
        nounlock = 0
        __PRETTY_FUNCTION__ = "handle_request_do"
#5  0x00007ff17ca8e7d2 in sipsock_read (id=0x7ff138000f70, fd=10, events=1, ignore=0x0) at chan_sip.c:28378
        req = {rlpart1 = 0, rlpart2 = 8, headers = 12, method = 1, lines = 14, sdp_start = 0, sdp_count = 14, debug = 0 '\000', has_to_tag = 1 '\001', ignore = 0 '\000',
          authenticated = 0 '\000', header = {0, 15, 84, 166, 256, 300, 360, 377, 469, 499, 519, 552, 572, 0 <repeats 51 times>}, line = {573, 577, 621, 641, 658, 664, 696, 717, 737,
            757, 778, 799, 833, 849, 0 <repeats 242 times>}, data = 0x7ff1380b89b0, content = 0x0, socket = {type = SIP_TRANSPORT_UDP, fd = -1, port = 50195, tcptls_session = 0x0,
            ws_session = 0x0}, next = {next = 0x0}, reqsipoptions = 0}
        addr = {ss = {ss_family = 2, __ss_align = 0,
            __ss_padding = "\000\000\000\000\001", '\000' <repeats 11 times>"\240, B\271\000\377\177\000\000\216{P\000\000\000\000\000\200\355\216x\361\177\000\000\320$U\001\000\000\000\000̣_\000\000\000\000\000ħ_\000\000\000\000\000\227 \322R>\001\000\000ģ_\000\000\000\000\000\350\003\000\000\000\000\000\000W\nN\306\361\177\000\000\320\355\216x\361\177\000\000@\002\000\000\000\000\000"}, len = 16}
        res = 889
        readbuf = "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 178.63.4.162:5060;branch=z9hG4bK4c97c67c;rport=5060\r\nContact: <sip:7125@109.202.18.205:50678;transport=UDP;rinstance=6ae9e0cbe69213e6>\r\nTo: <sip:7125@109.202.18.205:50"...
        __PRETTY_FUNCTION__ = "sipsock_read"
#6  0x0000000000501f9a in ast_io_wait (ioc=0x1552f30, howlong=576) at io.c:292
        res = 1
        x = 0
        origcnt = 1
#7  0x00007ff17ca90808 in do_monitor (data=0x0) at chan_sip.c:28976
        res = 576
        t = 1389502614
        reloading = 0
        __PRETTY_FUNCTION__ = "do_monitor"
#8  0x000000000059f064 in dummy_start (data=0x15848d0) at utils.c:1162
        __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, -3005536970000896347, 140733205529248, 140675086481856, 0, 3, -3005536970026062171, 3001862055355805349},
              __mask_was_saved = 0}}, __pad = {0x7ff1788eef80, 0x0, 0x0, 0x0}}
        __cancel_routine = 0x441827 <ast_unregister_thread>
        __cancel_arg = 0x7ff1788ef700
        __not_first_call = 0
        ret = 0x0
        a = {start_routine = 0x7ff17ca905df <do_monitor>, data = 0x0, name = 0x1586650 "do_monitor", ' ' <repeats 11 times>, "started at [29009] chan_sip.c restart_monitor()"}
#9  0x00007ff1c53a6e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#10 0x00007ff1c64ec3fd in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#11 0x0000000000000000 in ?? ()
No symbol table info available.

so it probably means that some 3CXPhone version causes segfault, right?

A bug in Asterisk causes the segfault, but something the phone does causes the port 0 issue, and presumably presumably sets up the pre-condition for the segfault. The SIP trace is needed to be more specific about what is putting Asterisk into a poorly tested code path.

Last 5 sec dump of SIP debug log

pastebin.com/Rjb9brqr

This is the line that is causing the initial diagnostic:

Your trace does not go back far enough to show the whole call, however it looks to me that the the phone is responding inappropriately to an unanswered call being abandoned. There is a CANCEL for the call immediately before the 200 OK which carries this “m audio 0”. That should have produced a request cancelled response, unless it collided with 200 OK. If it collided, you would not expect the phone to indicate that the call was on hold.

The 200 OK to CANCEL may have been sufficient to cause the crash, without the old style hold being present as well. However, because this could happen through a race condition, it is important that you raise a bug report.

Thanks for your reply.

Here is bigger dump dropbox.com/s/5ls653sv6ct52uu/dump.txt

I’ve already raised bug ticket in Jira, however no repsonse yet.

Cross linking this thread, and the bug report, both ways, would be a good idea.

Unfortunately, bugs can take some time to fix.

issues.asterisk.org/jira/browse/ASTERISK-23135

rolling back to 11.5.0 fixed the issue – no segfaults anymore