You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, when the ARI peer goes haywire and causes the websocket connection fail on the asterisk side, the sequence of freeing the context and calling the destroy hook gets reversed and the code experiences a use-after-free bug which eventually crashes the whole asterisk process:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f2cbb61f859 in __GI_abort () at abort.c:79
#2 0x00007f2cbb61f729 in __assert_fail_base
(fmt=0x7f2cbb7b5588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f2cbb9a762d "mutex->__data.__owner == 0", file=0x7f2cbb9a75fa "../nptl/pthread_mutex_lock.c", line=117, function=<optimized out>) at assert.c:92
#3 0x00007f2cbb630f36 in __GI___assert_fail
(assertion=assertion@entry=0x7f2cbb9a762d "mutex->__data.__owner == 0", file=file@entry=0x7f2cbb9a75fa "../nptl/pthread_mutex_lock.c", line=line@entry=117, function=function@entry=0x7f2cbb9a7790 <__PRETTY_FUNCTION__.10174> "__pthread_mutex_lock") at assert.c:101
#4 0x00007f2cbb99b1a9 in __GI___pthread_mutex_lock (mutex=<optimized out>) at ../nptl/pthread_mutex_lock.c:117
#5 0x00007f2c74e3f1ba in hook_destroy_cb (framedata=0x7f2c90012220) at res_ari_stream.c:121
#6 0x0000561aed810aac in framehook_detach (mode=FRAMEHOOK_DETACH_DESTROY, framehook=0x7f2c90012370) at framehook.c:78
#7 framehook_list_push_event (framehooks=<optimized out>, frame=frame@entry=0x7f2c4002af18, event=event@entry=AST_FRAMEHOOK_EVENT_READ) at framehook.c:106
#8 0x0000561aed81127b in ast_framehook_list_read_event (framehooks=<optimized out>, frame=frame@entry=0x7f2c4002af18) at framehook.c:320
#9 0x0000561aed7c4db0 in __ast_read (chan=chan@entry=0x7f2ca0004830, dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=1) at channel.c:3783
#10 0x0000561aed7c6c20 in ast_read (chan=chan@entry=0x7f2ca0004830) at channel.c:4291
#11 0x00007f2c7587f88e in stasis_app_exec (chan=chan@entry=0x7f2ca0004830, app_name=<optimized out>, argc=<optimized out>, argv=argv@entry=0x7f2c3ba22960) at res_stasis.c:1569
#12 0x00007f2c74c693c9 in app_exec (chan=0x7f2ca0004830, data=0x7f2ca00046c4 "hello1") at app_stasis.c:105
#13 0x0000561aed85146c in pbx_exec (c=0x7f2ca0004830, app=app@entry=0x561aef1ec590, data=data@entry=0x7f2ca00046c4 "hello1")
at /home/karel/asterisk/asterisk-18.6.0/include/asterisk/strings.h:67
#14 0x00007f2c7411d74c in ari_originate_dial (data=data@entry=0x7f2ca0000bc0) at ari/resource_channels.c:1030
#15 0x0000561aed8cde18 in dummy_start (data=<optimized out>) at utils.c:1428
#16 0x00007f2cbb998609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#17 0x00007f2cbb71c293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
The patch file to modify the original source code to replicate the test: res_ari_stream.patch.gz
The text was updated successfully, but these errors were encountered:
The code performs correctly for succesfull calls and as shown by adding few debugging lines:
However, when the ARI peer goes haywire and causes the websocket connection fail on the asterisk side, the sequence of freeing the context and calling the destroy hook gets reversed and the code experiences a use-after-free bug which eventually crashes the whole asterisk process:
The gdb backtrace for the latter case is:
The patch file to modify the original source code to replicate the test:
res_ari_stream.patch.gz
The text was updated successfully, but these errors were encountered: