[Freeswitch-users] loopback-b channels stay alive

[Tamas Cseke]

Hello,

We originate loopback channels and they end up in calling sofia
and transfer the call to a fifo.

If we have a heavy call volume loopback-b channels don't hangup properly.
They stay in core.db.
Unfortunetly we can't reproduce it on test boxes but happens every day. 
On this box we had to turn off debug logging, becase we had I/O problems.

The only thing I saw in log that switch_core_session_thread don't call

    switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_NOTICE, "Session %" 
SWITCH_SIZE_T_FMT " (%s) Ended\n",
                      session->id, 
switch_channel_get_name(session->channel));

in these cases.
We have local patches (I don't think they are related) and we are 
running FS on virtual machine and we had some problem with that before 
so I'm not sure, but I guess it is maybe a lock or mutex problem.

I tried SWITCH_DEBUG_RWLOCKS, but I got build error, and I don't know 
what to do with it.

FS_CFLAGS = -O2 -ffast-math -g -ggdb -DSWITCH_DEBUG_RWLOCKS
export CFLAGS="-O2 -ffast-math -g -ggdb -DSWITCH_DEBUG_RWLOCKS"
export MOD_CFLAGS="-O2 -ffast-math -g -ggdb -DSWITCH_DEBUG_RWLOCKS"
./configure

gcc -I/DEVEL/freeswitch/src/include 
-I/DEVEL/freeswitch/libs/libteletone/src -fPIC -Werror 
-fvisibility=hidden -DSWITCH_API_VISIBILITY=1 -DHAVE_VISIBILITY=1 -g 
-ggdb -O2 -ffast-math -g -ggdb -DSWITCH_DEBUG_RWLOCKS -Wall -std=c99 
-pedantic -o .libs/freeswitch freeswitch-switch.o  -lm 
./.libs/libfreeswitch.so libs/apr/.libs/libapr-1.a -lrt -ldl -lcrypt 
-lpthread libs/libedit/src/.libs/libedit.a -lncurses -Wl,--rpath 
-Wl,/opt/freeswitch//lib
./.libs/libfreeswitch.so: undefined reference to 
`switch_core_session_read_lock'
./.libs/libfreeswitch.so: undefined reference to 
`switch_core_session_locate'
./.libs/libfreeswitch.so: undefined reference to 
`switch_core_session_rwunlock'
collect2: ld returned 1 exit status
make[2]: *** [freeswitch] Error 1

Could you please tell me how could I test mutexes, rwlocks?

Other option would be to omit loopback channels.
Anthony earlier suggested me to avoid it and call sofia directly

"you could make the loopback channel execute the eval app and do the
originate to the sofia channel from the dialplan.

<action application="eval" data="${originate(sofia/foo/a at b.com xyz)}"/>
or make the loopback chan exec a lua or js and fire an originate command and
exit

This way you don't have the loopback a and b leg as well as the sofia chan."

but it doesn't work, because originate api doesn't let us originate inside a session.
So we still using it.


Thanks in advance,
Tamas