19 Feb
2014
19 Feb
'14
4:53 p.m.
On 05.02.2014 09:08, Daniel-Constantin Mierla wrote:
On 05/02/14 08:57, Øyvind Kolbu wrote:
Indeed, I checked 4.1, MEMDBG is set for the branch. You can set in
config:
mem_safety=1
Forgot to set mem_safety for a server after upgrading to post 4.1.1 git,
but crashed again:
(gdb) bt
#0 0x000000395c032925 in raise () from /lib64/libc.so.6
#1 0x000000395c034105 in abort () from /lib64/libc.so.6
#2 0x00000000005486e0 in qm_free (qm=0x7f6ec2dba000, p=0x7f6ec314ac68,
file=0x61c530 "<core>: mem/shm_mem.c", func=0x61cccc
"sh_realloc", line=88)
at mem/q_malloc.c:470
#3 0x000000000054e70e in sh_realloc (p=0x7f6ec314ac68, size=720) at
mem/shm_mem.c:88
#4 0x000000000054e8ad in _shm_resize (p=0x7f6ec314ac68, s=720,
file=0x7f6ecfe249cb "tm: t_reply.c", func=0x7f6ecfe272b1
"relay_reply",
line=1949)
at mem/shm_mem.c:114
#5 0x00007f6ecfdeef4b in relay_reply (t=0x7f6ec40aab28,
p_msg=0x7f6ed130c5a0, branch=3, msg_status=180,
cancel_data=0x7fff1a264320, do_put_on_wait=1)
at t_reply.c:1948
#6 0x00007f6ecfdf17b6 in reply_received (p_msg=0x7f6ed130c5a0) at
t_reply.c:2491
#7 0x000000000045d66f in do_forward_reply (msg=0x7f6ed130c5a0, mode=0)
at forward.c:777
#8 0x000000000045df30 in forward_reply (msg=0x7f6ed130c5a0) at
forward.c:860
#9 0x00000000004a558f in receive_msg (
buf=0x9235e0 "SIP/2.0 180 Ringing\r\nVia: SIP/2.0/UDP
129.240.254.5;branch=z9hG4bK823a.f082d80b4a3abcb7dbdfb45c4218c5bb.3\r\nVia:
SIP/2.0/UDP
129.240.254.71:5060;branch=z9hG4bK236fae70;rport=5060\r\nFrom: \"56435\"
<sip:56"..., len=646, rcv_info=0x7fff1a2646a0) at receive.c:273
#10 0x000000000053c394 in udp_rcv_loop () at udp_server.c:536
#11 0x000000000046d263 in main_loop () at main.c:1617
#12 0x000000000047030b in main (argc=21, argv=0x7fff1a2649d8) at main.c:2533
# /usr/sbin/kamailio -V
version: kamailio 4.1.1 (x86_64/linux)
flags: STATS: Off, 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, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 17:13:06 Jan 29 2014 with gcc 4.4.7
gitrev d0e32ab598ec13756da96dbc3651aaae72bfd92b
--
Øyvind
-----Original Message-----
From: Daniel-Constantin Mierla
Sent: Tuesday, February 04, 2014 9:26 PM
Hello,
this happens due to an abort() that is executed only when MEMDBG is set
(memory debugging is turned on). It's main purpose is to spot double
frees.
For production, either MEMDBG is not set or you set mem_safety global
parameter. You will get the log message, but the application keeps
running.
I also recommend to upgrade to 4.1.1, there were some fixes that
affect this
case as well.
On the other side, I will try to see what could be the situation to
end in the
two frees once I get a chance (still in the middle of a traveling
period for a
while here).
OK, will try a git after 4.1.1. I'm keeping the core file if you
want
it or a full backtrace.
Both MEMDBG and mem_safety are default. Neither config nor build
changes them.