[asterisk-users] [External] Encountered a crash, what is best way to tell if it has been fixed or now

Wed Aug 9 14:10:58 CDT 2023

I was able to put the crash through the gdb on the original VM that encountered the problem.
(Not sure why the VM I initially tried to analyze the crash dump on didn’t do this correctly, but not concerned about it now).

It’s providing additional details.

Would this be considered a better example of the crash?
I will go through the version comparisons and see if there are any updates since 18.17.1 to see if I can spot any fixes or recent commits.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055e7c091ed95 in __ao2_ref (user_data=user_data at entry=0x1, delta=delta at entry=1, tag=tag at entry=0x0, file=file at entry=0x7f773800e012 "res_pjsip_session.c", line=line at entry=3639,
    func=func at entry=0x7f7738011d20 <__PRETTY_FUNCTION__.38105> "ast_sip_dialog_get_session") at astobj2.c:501
501     astobj2.c: No such file or directory.
[Current thread is 1 (Thread 0x7f772c1a1700 (LWP 124120))]
(gdb) bt
#0  0x000055e7c091ed95 in __ao2_ref (user_data=user_data at entry=0x1, delta=delta at entry=1, tag=tag at entry=0x0, file=file at entry=0x7f773800e012 "res_pjsip_session.c", line=line at entry=3639,
    func=func at entry=0x7f7738011d20 <__PRETTY_FUNCTION__.38105> "ast_sip_dialog_get_session") at astobj2.c:501
#1  0x00007f773800a0da in ast_sip_dialog_get_session (dlg=dlg at entry=0x7f777415de48) at res_pjsip_session.c:3639
#2  0x00007f773800d3e7 in session_outgoing_nat_hook (tdata=0x7f773c633ac8, transport=0x7f7754082048) at res_pjsip_session.c:5567
#3  0x00007f773801965d in nat_invoke_hook (obj=<optimized out>, arg=arg at entry=0x7f772c1a0a50, flags=flags at entry=0) at res_pjsip_nat.c:299
#4  0x000055e7c09218c0 in internal_ao2_traverse (self=self at entry=0x7f774014cc18, flags=flags at entry=OBJ_SEARCH_NONE, cb_fn=cb_fn at entry=0x7f7738019640 <nat_invoke_hook>, arg=arg at entry=0x7f772c1a0a50, tag=tag at entry=0x0,
    file=file at entry=0x7f773801b009 "res_pjsip_nat.c", line=<optimized out>, func=<optimized out>, type=AO2_CALLBACK_DEFAULT, data=0x0) at astobj2_container.c:328
#5  0x000055e7c0921d79 in __ao2_callback (c=c at entry=0x7f774014cc18, flags=flags at entry=OBJ_SEARCH_NONE, cb_fn=cb_fn at entry=0x7f7738019640 <nat_invoke_hook>, arg=arg at entry=0x7f772c1a0a50, tag=tag at entry=0x0,
    file=file at entry=0x7f773801b009 "res_pjsip_nat.c", line=470, func=0x7f773801b4b8 <__PRETTY_FUNCTION__.29250> "process_nat") at astobj2_container.c:414
#6  0x00007f7738019ddf in process_nat (tdata=0x7f773c633ac8) at res_pjsip_nat.c:470
#7  nat_on_tx_message (tdata=0x7f773c633ac8) at res_pjsip_nat.c:479
#8  0x00007f777bc6fc66 in endpt_on_tx_msg (endpt=<optimized out>, tdata=0x7f773c633ac8) at ../src/pjsip/sip_endpoint.c:1115
#9  0x00007f777bc77c69 in pjsip_transport_send (tr=0x55e7c1ac7708, tdata=tdata at entry=0x7f773c633ac8, addr=addr at entry=0x7f773c633cb8, addr_len=addr_len at entry=16, token=token at entry=0x7f773c635950,
    cb=cb at entry=0x7f777bc71610 <stateless_send_transport_cb>) at ../src/pjsip/sip_transport.c:935
#10 0x00007f777bc717d9 in stateless_send_transport_cb (token=token at entry=0x7f773c635950, tdata=tdata at entry=0x7f773c633ac8, sent=<optimized out>, sent at entry=-70002) at ../src/pjsip/sip_util.c:1276
#11 0x00007f777bc71b3a in stateless_send_resolver_callback (status=<optimized out>, token=0x7f773c635950, addr=<optimized out>) at ../src/pjsip/sip_util.c:1377
#12 0x00007f77380c3398 in sip_resolve_invoke_user_callback (data=0x7f773c4563c8) at res_pjsip/pjsip_resolver.c:206
#13 0x000055e7c0a6f0e3 in ast_taskprocessor_execute (tps=tps at entry=0x7f775416ebc0) at taskprocessor.c:1302
#14 0x000055e7c0a76d28 in execute_tasks (data=0x7f775416ebc0) at threadpool.c:1352
#15 0x000055e7c0a6f0e3 in ast_taskprocessor_execute (tps=0x55e7c2697720) at taskprocessor.c:1302
#16 0x000055e7c0a7760c in threadpool_execute (pool=0x55e7c269be10) at threadpool.c:367
#17 worker_active (worker=0x7f7770001740) at threadpool.c:1137
#18 worker_start (arg=arg at entry=0x7f7770001740) at threadpool.c:1056
#19 0x000055e7c0a7f868 in dummy_start (data=<optimized out>) at utils.c:1574
#20 0x00007f777b4ba609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#21 0x00007f777b23c133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Dan

From: asterisk-users <asterisk-users-bounces at lists.digium.com> On Behalf Of Joshua C. Colp
Sent: Wednesday, August 9, 2023 1:31 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Subject: Re: [External] [asterisk-users] Encountered a crash, what is best way to tell if it has been fixed or now

On Wed, Aug 9, 2023 at 3:20 PM Dan Cropp <dcropp at amtelco.com<mailto:dcropp at amtelco.com>> wrote:
I have a customer who just encountered a crash while running Asterisk 18.17.1 version.

I’m trying to adapt to the changes so not sure where best to look or how to possibly report this.

I started by going through https://github.com/asterisk/asterisk/compare/18.17.1...18.19.0 to see if any of the changes seemed to apply to code reported by the backtrace.

Entirely possible I missed something, but I didn’t notice anything that applies.

I do see a commit was done today to the res_pjsip_nat.c file, but not sure if that would apply to the issue.

Any suggestions for where I should look or ask?

That is how you generally look, by seeing the commits between the two versions, analyzing, and seeing if anything is relevant.

Issues themselves are reported on Github. I can say already though that the backtrace is incomplete and doesn't show the full story of what happened, it may be optimized or something.

--
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com<http://www.sangoma.com> and www.asterisk.org<http://www.asterisk.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20230809/17486f3a/attachment.html>