<div dir="ltr"><div>Hi, Everyone!<br></div><div><br></div><div>I think I have found a crash.</div><div><br></div><div>Bit of background: I am on asterisk 16.6.2 and the box itself is handling ~  500 simultaneous calls.</div><div>The whole call management part is fully handled by Stasis app through ARI.</div><div><br></div><div>With a recent bug with our own Stasis software (multiple consecutive bridge destroys in a row) we have spotted an asterisk crash on rare occasions:</div><div><br></div><div>#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51<br>#1  0x00007f7e96b77801 in __GI_abort () at abort.c:79<br>#2  0x00007f7e96bc0897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f7e96cedb9a "%s\n")<br>    at ../sysdeps/posix/libc_fatal.c:181<br>#3  0x00007f7e96bc790a in malloc_printerr (str=str@entry=0x7f7e96cef828 "double free or corruption (fasttop)")<br>    at malloc.c:5350<br>#4  0x00007f7e96bcf004 in _int_free (have_lock=0, p=0x7f7e7c01d670, av=0x7f7e7c000020) at malloc.c:4230<br>#5  __GI___libc_free (mem=0x7f7e7c01d680) at malloc.c:3124<br>#6  0x000055997dfc833d in __ast_free (ptr=<optimized out>, file=file@entry=0x55997e1afe4f "bridge_roles.c",<br>    lineno=lineno@entry=78, func=func@entry=0x55997e1b0150 <__PRETTY_FUNCTION__.14665> "bridge_role_destroy")<br>    at astmm.c:1577<br>#7  0x000055997dff8779 in bridge_role_destroy (role=<optimized out>) at bridge_roles.c:78<br>#8  ast_channel_clear_bridge_roles (chan=<optimized out>) at bridge_roles.c:374<br>#9  0x00007f7e35d9d71a in bridge_stasis_pull (self=0x7f7dc8001020, bridge_channel=0x7f7e7012adf0)<br>    at stasis/stasis_bridge.c:292<br>#10 0x000055997dff5239 in bridge_channel_internal_pull (bridge_channel=bridge_channel@entry=0x7f7e7012adf0)<br>    at bridge_channel.c:2170<br>#11 0x000055997dff67da in bridge_channel_internal_join (bridge_channel=bridge_channel@entry=0x7f7e7012adf0)<br>    at bridge_channel.c:2921<br>#12 0x000055997dfdc045 in bridge_channel_depart_thread (data=data@entry=0x7f7e7012adf0) at bridge.c:1787<br>#13 0x000055997e122f85 in dummy_start (data=<optimized out>) at utils.c:1249<br>#14 0x00007f7e9771f6db in start_thread (arg=0x7f7d6f6b8700) at pthread_create.c:463<br>#15 0x00007f7e96c5888f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95<br></div><div><br></div><div><br></div><div>I suspect it could be a race condition where there are multiple attempts to free same memory segment (after it has already been freed).</div><div>Although - we will apply fix ourselves to remedy the issue for our case; is there anything else, you would need from me, to be able to fix this for other people?</div><div><br></div><div class="gmail_quote"></div></div>