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
Describe the bug
I am consistently getting a segmentation fault on retrieving certain variables using session:getVariable in LUA
The variables are bleg_created_time and bleg_answered_time and are called after hangup of the bridged call leg. The session itself is still alive and the a-leg is still connected.
I found this post on retrieving bleg variables after bridge and I have changed our application to not rely on these variables anymore, so it is not the actual variables that I want fixed. What I would like is that Freeswitch does not crash when calling a function like session:getVariable , especially with variable names that are legitimate at some time during a call.
To Reproduce
Bridge a call
Hangup the bridge call (callee or b-leg)
With caller still active, call session:getVariable('bleg_created_time')
FreeSWITCH crashes
Expected behavior
Nil or empty variable on getVariable or a recoverable error.
Package version
1.10.12-release-10222002881-a88d069d6f~bullseye
1.10.11
Trace logs
No logging available; only kernel logs show a segmentation fault
backtrace from core file
Backtrace excerpt:
#0 0x00007efecb5d8786 in switch_caller_get_field_by_name (caller_profile=0x7efec4035ae8, name=name@entry=0x7efec401f0fd "created_time") at src/switch_caller.c:292
#1 0x00007efecb5db61f in switch_channel_get_variable_dup (channel=0x7efea403bba0, varname=0x7efec401f0fd "created_time", dup=dup@entry=SWITCH_TRUE, idx=idx@entry=-1) at src/switch_channel.c:1004
#2 0x00007efecb713f8e in CoreSession::getVariable (this=<optimized out>, var=<optimized out>) at src/switch_cpp.cpp:782
#3 0x00007efeb29517b2 in _wrap_CoreSession_getVariable (L=0x7efec40191f0) at mod_lua_wrap.cpp:6453
#4 0x00007efeb2901f2e in luaD_precall (L=L@entry=0x7efec40191f0, func=<optimized out>, func@entry=0x7efec4030d90, nresults=nresults@entry=1) at ldo.c:319
#5 0x00007efeb290dcfc in luaV_execute (L=L@entry=0x7efec40191f0) at lvm.c:709
#6 0x00007efeb29022d8 in luaD_call (L=0x7efec40191f0, func=<optimized out>, nResults=<optimized out>, allowyield=<optimized out>) at ldo.c:402
#7 0x00007efeb290184f in luaD_rawrunprotected (L=L@entry=0x7efec40191f0, f=f@entry=0x7efeb28fcee0 <f_call>, ud=ud@entry=0x7efec942c2a0) at ldo.c:131
#8 0x00007efeb290251f in luaD_pcall (L=L@entry=0x7efec40191f0, func=func@entry=0x7efeb28fcee0 <f_call>, u=u@entry=0x7efec942c2a0, old_top=64, ef=<optimized out>) at ldo.c:603
#9 0x00007efeb28fe481 in lua_pcallk (L=L@entry=0x7efec40191f0, nargs=nargs@entry=0, nresults=nresults@entry=0, errfunc=errfunc@entry=3, ctx=ctx@entry=0, k=k@entry=0x0) at lapi.c:949
#10 0x00007efeb294041b in docall (L=L@entry=0x7efec40191f0, narg=narg@entry=0, nresults=nresults@entry=0, perror=perror@entry=0, fatal=fatal@entry=1) at mod_lua.cpp:92
#11 0x00007efeb2940969 in lua_parse_and_execute (L=0x7efec40191f0, input_code=0x7efec4007e40 "follow_up_call.lua", session=0x7efea403dac8) at mod_lua.cpp:194
#12 0x00007efeb2941544 in lua_parse_and_execute (session=0x7efea403dac8, input_code=0x7efec4007e40 "follow_up_call.lua", L=0x7efec40191f0) at ../../../../src/include/switch_utils.h:308
#13 lua_function (session=0x7efea403dac8, data=<optimized out>) at mod_lua.cpp:482
#14 0x00007efecb60b7b5 in switch_core_session_exec (session=session@entry=0x7efea403dac8, application_interface=application_interface@entry=0x55e72ab507f0, arg=0x7efec40b3cf8 "follow_up_call.lua bridge") at src/switch_core_session.c:2965
#15 0x00007efecb60bff0 in switch_core_session_execute_application_get_flags (session=session@entry=0x7efea403dac8, app=0x7efec40b3cf0 "lua", arg=<optimized out>, flags=flags@entry=0x0) at src/switch_core_session.c:2825
#16 0x00007efecb610452 in switch_core_standard_on_execute (session=0x7efea403dac8) at src/switch_core_state_machine.c:350
#17 switch_core_session_run (session=0x7efea403dac8) at src/switch_core_state_machine.c:647
#18 0x00007efecb6091a0 in switch_core_session_thread (thread=<optimized out>, obj=0x7efea403dac8) at src/switch_core_session.c:1727
#19 0x00007efecb6047ae in switch_core_session_thread_pool_worker (thread=0x7efea4062d80, obj=<optimized out>) at src/switch_core_session.c:1791
#20 0x00007efecb550ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#21 0x00007efecb470acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
#0 0x00007efecb5d8786 in switch_caller_get_field_by_name (caller_profile=0x7efec4035ae8, name=name@entry=0x7efec401f0fd "created_time") at src/switch_caller.c:292
Describe the bug
I am consistently getting a segmentation fault on retrieving certain variables using session:getVariable in LUA
The variables are bleg_created_time and bleg_answered_time and are called after hangup of the bridged call leg. The session itself is still alive and the a-leg is still connected.
I found this post on retrieving bleg variables after bridge and I have changed our application to not rely on these variables anymore, so it is not the actual variables that I want fixed. What I would like is that Freeswitch does not crash when calling a function like session:getVariable , especially with variable names that are legitimate at some time during a call.
To Reproduce
Expected behavior
Nil or empty variable on getVariable or a recoverable error.
Package version
Trace logs
No logging available; only kernel logs show a segmentation fault
backtrace from core file
Backtrace excerpt:
Full trace; fsbt.log
The text was updated successfully, but these errors were encountered: