Unfortunately, the commit did not resolve the issue.
This looks related to a lock inversion between channel hang up and the bridging code. There is an issue open for this ASTERISK-26445<https://issues.asterisk.org/jira/browse/ASTERISK-26445> While writing I have also had the following segfault: [Current thread is 1 (Thread 0x7efeed3d4700 (LWP 27169))] #0 0x00007effa2cefa28 in raise () at /lib64/libc.so.6 #1 0x00007effa2cf162a in abort () at /lib64/libc.so.6 #2 0x00007effa2d32dea in () at /lib64/libc.so.6 #3 0x00007effa2d3b22a in _int_free () at /lib64/libc.so.6 #4 0x00007effa2d3e78c in free () at /lib64/libc.so.6 #5 0x00007effa5c73aa4 in default_block_free (factory=0x7eff13bee000 <caching_pool>, mem=0x7eff64c600d0, size=4096) at ../src/pj/pool_policy_malloc.c:78 #6 0x00007effa5c7b9ce in pj_pool_destroy_int (pool=0x7eff64c600d0) at ../src/pj/pool.c:296 initial_size = 4096 #7 0x00007effa5c7c1aa in cpool_release_pool (pf=0x7eff13bee000 <caching_pool>, pool=0x7eff64c600d0) at ../src/pj/pool_caching.c:238 cp = 0x7eff13bee000 <caching_pool> pool_capacity = 12096 i = 32511 #8 0x00007effa5c7b1ef in pj_pool_release (pool=0x7eff64c600d0) at ../include/pj/pool_i.h:92 #9 0x00007effa5be5f11 in pjsip_rx_data_free_cloned (rdata=0x7eff54259678) at ../src/pjsip/sip_transport.c:730 #10 0x00007eff139c8968 in distribute (data=0x7eff54259678) at res_pjsip/pjsip_distributor.c:779 param = {start_prio = 0, start_mod = 0x7eff13becc40 <distributor_mod>, idx_after_start = 1, silent = 0} handled = 1 rdata = 0x7eff54259678 is_request = <optimized out> endpoint = <optimized out> #11 0x00000000005ee88f in ast_taskprocessor_execute (tps=0x3f14250) at taskprocessor.c:965 local = {local_data = 0x7efeed3d4700, data = 0x5f6012 <ast_threadstorage_set_ptr+60>} t = 0x7eff55977e50 size = 66142800 __PRETTY_FUNCTION__ = "ast_taskprocessor_execute" #12 0x00000000005f8444 in execute_tasks (data=0x3f14250) at threadpool.c:1322 tps = 0x3f14250 #13 0x00000000005ee88f in ast_taskprocessor_execute (tps=0x27180a0) at taskprocessor.c:965 local = {local_data = 0x7efeed3d3c80, data = 0x2691c60} t = 0x7eff5484bc60 size = 40443032 __PRETTY_FUNCTION__ = "ast_taskprocessor_execute" #14 0x00000000005f66f9 in threadpool_execute (pool=0x2691cb0) at threadpool.c:351 __PRETTY_FUNCTION__ = "threadpool_execute" #15 0x00000000005f7db0 in worker_active (worker=0x7eff940097c0) at threadpool.c:1105 alive = 0 #16 0x00000000005f7b68 in worker_start (arg=0x7eff940097c0) at threadpool.c:1024 worker = 0x7eff940097c0 saved_state = (DEAD | unknown: 32508) __PRETTY_FUNCTION__ = "worker_start" #17 0x000000000060402e in dummy_start (data=0x7eff94009260) at utils.c:1235 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, -3586398186740987612, 139633997204095, 139633367009024, 507904, 507904, -3586398186715821788, 3731046902439921956}, __mask_was_saved = 0}}, __pad = {0x7efeed3d3df0, 0x0, 0x1, 0x7effa3c936e8 <__pthread_keys+1032>}} __cancel_routine = 0x452814 <ast_unregister_thread> __cancel_arg = 0x7efeed3d4700 __not_first_call = 0 ret = 0x7effa30728d8 a = {start_routine = 0x5f7ae1 <worker_start>, data = 0x7eff940097c0, name = 0x7eff9410c6e0 "worker_start started at [ 1079] threadpool.c worker_thread_start()"} #18 0x00007effa3a8161a in start_thread () at /lib64/libpthread.so.0 #19 0x00007effa2dbd5fd in clone () at /lib64/libc.so.6 Should an issue be raised for this? Regards, Ross ________________________________ From: asterisk-dev-boun...@lists.digium.com <asterisk-dev-boun...@lists.digium.com> on behalf of Ross Beer <ross.b...@outlook.com> Sent: 08 February 2017 18:17 To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] Deadlock GIT 13 Hi Mark, It does indeed, the patch has just been committed so I will check out the latest from git. Thank you for your swift reply. Kind regards, Ross ________________________________ From: asterisk-dev-boun...@lists.digium.com <asterisk-dev-boun...@lists.digium.com> on behalf of Mark Michelson <mmichel...@digium.com> Sent: 08 February 2017 17:55 To: Asterisk Developers Mailing List Subject: Re: [asterisk-dev] Deadlock GIT 13 On 02/08/2017 11:26 AM, Ross Beer wrote: Hi, I'm getting a deadlock every so often with asterisk 13 GIT. There are a lot of low level locks: #0 0x00007f64ca6f052d in nanosleep () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7f64cdcc9700 (LWP 20745))] #0 0x00007f64ca6f052d in nanosleep () at /lib64/libc.so.6 #1 0x00007f64ca6f03c4 in sleep () at /lib64/libc.so.6 #2 0x00000000004fc844 in db_sync_thread (data=0x0) at db.c:980 __PRETTY_FUNCTION__ = "db_sync_thread" #3 0x000000000060401e in dummy_start (data=0x1e04440) at utils.c:1235 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, -361566044794415684, 140733401961727, 140070926194432, 507904, 0, -361566044802804292, 302566635355346364}, __mask_was_saved = 0}}, __pad = {0x7f64cdcc8df0, 0x0, 0x0, 0x0}} __cancel_routine = 0x452814 <ast_unregister_thread> __cancel_arg = 0x7f64cdcc9700 __not_first_call = 0 ret = 0x7f64cdcc8df0 a = {start_routine = 0x4fc765 <db_sync_thread>, data = 0x0, name = 0x1e055b0 "db_sync_thread started at [ 1022] db.c astdb_init()"} #4 0x00007f64cb3ee61a in start_thread (arg=0x7f64cdcc9700) at pthread_create.c:334 __res = <optimized out> pd = 0x7f64cdcc9700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140070926194432, 302565808931837372, 140733401961727, 140070926194432, 507904, 0, -361566044792318532, -361562863565433412}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> #5 0x00007f64ca72a5fd in clone () at /lib64/libc.so.6 Should an issue be created on Jira? Regards, Ross Hi Ross, This may be the same issue that George discovered earlier today while doing some testing. If you apply the code change on this review https://gerrit.asterisk.org/#/c/4902/ , do you still see the issue? Gerrit Code Review<https://gerrit.asterisk.org/#/c/4902/> gerrit.asterisk.org gerrit.asterisk.org runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in ... Mark Michelson
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev