FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a versatile software implementation that runs on any commodity hardware. From a Raspberry PI to a multi-core server, FreeSWITCH can unlock the telecommunications potential of any device.
Describe the bug
I am consistently getting a segmentation fault on retrieving certain variables using session:getVariable in LUA
The variables are _bleg_createdtime and _bleg_answeredtime 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
mariahyang
commented
1 week ago
Describe the bug I am consistently getting a segmentation fault on retrieving certain variables using session:getVariable in LUA The variables are _bleg_createdtime and _bleg_answeredtime 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