ERROR - Failed assertion bad magic number

[leonardo]

Dear.

We have an Asterisk 13.38.3, where there was the following situation.

Log Full at the time of the error:

ERROR[14139] astobj2.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x473f628 (0)
ERROR[14139] : Got 12 backtrace records
#0: /usr/sbin/asterisk(__ao2_lock+0x167) [0x45b697]
#1: /usr/lib64/asterisk/modules/chan_sip.so(+0x99542) [0x7f464735e542]
#2: /usr/lib64/asterisk/modules/chan_sip.so(+0x9bd4d) [0x7f4647360d4d]
#3: /usr/lib64/asterisk/modules/chan_sip.so(+0x9e15b) [0x7f464736315b]
#4: /usr/lib64/asterisk/modules/chan_sip.so(+0x9fe09) [0x7f4647364e09]
#5: /usr/lib64/asterisk/modules/res_http_websocket.so(__ast_websocket_uri_cb+0x8f4) [0x7f4702f28394]
#6: /usr/sbin/asterisk() [0x5277b5]
#7: /usr/sbin/asterisk() [0x527b99]
#8: /usr/sbin/asterisk() [0x5e352d]
#9: /usr/sbin/asterisk() [0x5f277a]
#10: /usr/lib64/libpthread.so.0(+0x7dd5) [0x7f471ab15dd5]
#11: /usr/lib64/libc.so.6(clone+0x6d) [0x7f4719bb5ead]

BACKTRACER :

#0 0x00007f471ab1d49b in raise () from /usr/lib64/libpthread.so.0
#1 0x00007f469b22742e in skgesigOSCrash () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#2 0x00007f469b4c9ca9 in kpeDbgSignalHandler () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#3 0x00007f469b22763e in skgesig_sigactionHandler () from /usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1
#4
#5 __ast_string_field_ptr_grow (mgr=mgr@entry=0x473f770, pool_head=pool_head@entry=0x473f678, needed=needed@entry=28, ptr=ptr@entry=0x473f6e8)
at stringfields.c:277
#6 0x00007f46473296c1 in parse_register_contact (pvt=pvt@entry=0x7f4528022ec8, peer=peer@entry=0x473f628, req=req@entry=0x7f4577a1fe40) at chan_sip.c:16962
#7 0x00007f464735edfa in register_verify (p=p@entry=0x7f4528022ec8, addr=addr@entry=0x7f452800a538, req=req@entry=0x7f4577a1fe40,
uri=uri@entry=0x7f452801dbb1 "sip:sip.host.com.br") at chan_sip.c:17893
#8 0x00007f4647360d4d in handle_request_register (e=0x7f452801dbb1 “sip:sip.host.com.br”, addr=0x7f452800a538, req=0x7f4577a1fe40, p=0x7f4528022ec8)
at chan_sip.c:28803
#9 handle_incoming (p=p@entry=0x7f4528022ec8, req=req@entry=0x7f4577a1fe40, addr=addr@entry=0x7f452800a538, recount=recount@entry=0x7f4577a1fae0,
nounlock=nounlock@entry=0x7f4577a1fb00) at chan_sip.c:29111
#10 0x00007f464736315b in handle_request_do (req=req@entry=0x7f4577a1fe40, addr=0x7f452800a538) at chan_sip.c:29279
#11 0x00007f4647364e09 in sip_websocket_callback (session=0x7f452800a528, parameters=, headers=) at chan_sip.c:2668
#12 0x00007f4702f28394 in __ast_websocket_uri_cb (ser=0x7f46bc012608, urih=, uri=, method=,
get_vars=, headers=) at res_http_websocket.c:956
#13 0x00000000005277b5 in handle_uri (headers=0x7f4528024f50, method=AST_HTTP_GET, uri=0x7f4577a20ae7 “”, ser=0x7f4577a21ae0) at http.c:1502
#14 httpd_process_request (ser=ser@entry=0x7f46bc012608) at http.c:1943
#15 0x0000000000527b99 in httpd_helper_thread (data=0x7f46bc012608) at http.c:2018
#16 0x00000000005e352d in handle_tcptls_connection (data=data@entry=0x7f46bc012608) at tcptls.c:857
#17 0x00000000005f277a in dummy_start (data=) at utils.c:1239
#18 0x00007f471ab15dd5 in start_thread () from /usr/lib64/libpthread.so.0
#19 0x00007f4719bb5ead in clone () from /usr/lib64/libc.so.6

Observation : Alterado o host apenas por segurança!

I need help figuring out the cause of the asterisk crash, based on the above logs.

Thank you so much!

[david551]

It was parsing the Contact header on a register request, using the deprecated chan_sip driver, on an end of life version of Asterisk.

More specifically, it was doing this:

/* Store whatever we got as a contact from the client */
	ast_string_field_set(peer, fullcontact, curi);

where peer is a pointer the data structure that represents the type=peer entry.

And it looks like there was a problem with the memory pool used for strings.

@entry is a new one on me. I wonder if it is an attempt to improve on “optimised out”, in which case, if you were dealing with a supported version, you would need to recompile with NOOPTIMISE to get better debugging.

You will need to look at other information to work out what you were doing that was unusual at the time. Note that such errors may be the result of actions by other threads, and could be the result of memory corruption, so the actual cause could be unrelated to what is shown in the backtrace.