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@entry=0x1, delta=delta@entry=1, tag=tag@entry=0x0, file=file@entry=0x7f773800e012 "res_pjsip_session.c", line=line@entry=3639, func=func@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@entry=0x1, delta=delta@entry=1, tag=tag@entry=0x0, file=file@entry=0x7f773800e012 "res_pjsip_session.c", line=line@entry=3639, func=func@entry=0x7f7738011d20 <__PRETTY_FUNCTION__.38105> "ast_sip_dialog_get_session") at astobj2.c:501 #1 0x00007f773800a0da in ast_sip_dialog_get_session (dlg=dlg@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@entry=0x7f772c1a0a50, flags=flags@entry=0) at res_pjsip_nat.c:299 #4 0x000055e7c09218c0 in internal_ao2_traverse (self=self@entry=0x7f774014cc18, flags=flags@entry=OBJ_SEARCH_NONE, cb_fn=cb_fn@entry=0x7f7738019640 <nat_invoke_hook>, arg=arg@entry=0x7f772c1a0a50, tag=tag@entry=0x0, file=file@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@entry=0x7f774014cc18, flags=flags@entry=OBJ_SEARCH_NONE, cb_fn=cb_fn@entry=0x7f7738019640 <nat_invoke_hook>, arg=arg@entry=0x7f772c1a0a50, tag=tag@entry=0x0, file=file@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@entry=0x7f773c633ac8, addr=addr@entry=0x7f773c633cb8, addr_len=addr_len@entry=16, token=token@entry=0x7f773c635950, cb=cb@entry=0x7f777bc71610 <stateless_send_transport_cb>) at ../src/pjsip/sip_transport.c:935 #10 0x00007f777bc717d9 in stateless_send_transport_cb (token=token@entry=0x7f773c635950, tdata=tdata@entry=0x7f773c633ac8, sent=<optimized out>, sent@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@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@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-boun...@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@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 <dcr...@amtelco.com<mailto:dcr...@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>
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users