Hi All,
I'm observing a core intermittently at "qm_status (qm=0x786cd000) at
mem/q_malloc.c:763" for kamailio version 3.1.0
looking at the backtrace this is occurring while doing a tcp buffer
overrun. Please have a look and let me know if anyone observed this issue
or how can we debug it.
Please find the backtrace and kamailio version
osbprod-V2R0:~ # /usr/sbin/kamailio -V
version: kamailio 3.1.0 (i386/linux) 21a375
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 15MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 21a375
compiled on 12:38:44 Apr 26 2012 with gcc 4.5.0
#0 qm_status (qm=0x786cd000) at mem/q_malloc.c:763
#1 0x0819c0f3 in qm_debug_frag (qm=0x786cd000, f=<value optimized out>) at
mem/q_malloc.c:167
#2 0x0819c352 in qm_free (qm=0x786cd000, p=0x7a6cb6ac, file=0x821cce2
"<core>: tcp_main.c", func=0x822285f "wbufq_run", line=880) at
mem/q_malloc.c:457
#3 0x0815f686 in wbufq_run (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at
tcp_main.c:880
#4 handle_tcpconn_ev (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at tcp_main.c:4141
#5 0x08169bf2 in io_wait_loop_epoll () at io_wait.h:1092
#6 tcp_main_loop () at tcp_main.c:4606
#7 0x080b0404 in main_loop () at main.c:1655
#8 0x080b1f84 in main (argc=9, argv=0xbfb4c9f4) at main.c:2446
(gdb) l
758 LOG_(DEFAULT_FACILITY, memlog, "qm_status: ",
759 "dumping free list stats :\n");
760 for(h=0,i=0;h<QM_HASH_SIZE;h++){
761 unused=0;
762 for (f=qm->free_hash[h].head.u.nxt_free,j=0;
763 f!=&(qm->free_hash[h].head);
f=f->u.nxt_free, i++, j++){
764 if (!FRAG_WAS_USED(f)){
765 unused++;
766 #ifdef DBG_QM_MALLOC
767 LOG_(DEFAULT_FACILITY,
memlog, "qm_status: ",
Hi,
I want to configure Kamailio so that it sends a NOTIFY using the tcp
connection already established by the client SUBSCRIBE request. The aim is
for clients to establish secure TLS connections to Kamailio when they first
register or subscribe, then for kamailio to reuse these connections for all
further NOTIFY/INVITE requests. I thought that adding force_tcp_alias() in
the route script would accomplish this, but it doesn't. The NOTIFY always
uses the ip:port tuple specified in the SUBSCRIBE Contact header.
Can anyone shed any light on this?
Thanks,
Owen Lynch