THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#247 - Kamailio version 3.1.2 crash when memory realloc
User who did this - Daniel-Constantin Mierla (miconda)
----------
There is a safety check of realloc with size 0, so this should not happen. I guess you recompiled with fm_malloc support, afaik, 3.1.x is with qm_malloc.
Did you get the situation again? Same backtrace?
It was reported that libssl can do free(0), so I added recently a check for that case. Probably is unrelated, but maybe it worth trying that patch.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=247#comment726
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#236 - Kamailio crash when about 300,000 tls connections opened.
User who did this - Daniel-Constantin Mierla (miconda)
----------
Can you use benchmark module to detect what parts are slow? Is the config processing or before it?
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=236#comment725
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#234 - kamailio crah [pass_fd.c:293]: ERROR: receive_fd: EOF on 46
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
Additional comments about closing: No follow up after the last commits. Try again with latest git version and reopen if the issue is still there.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=234
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi (Daniel this may be for you re. async)
Is it possible to get the sip message from a transaction after using
t_continue. The reason I ask is that using the async "pattern", how would
one be able to use transactional replies in code using t_reply(code,
message). Is the only way to store the sip_msg in shm for later use,
because if I look at TM I see there is no storage for the original SIP
request?
Cheers
Jason
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Bayan Towfiq (btowfiq)
Attached to Project - sip-router
Summary - 3.1.2 memory crash
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Critical
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - Kamailio is not generating cores but here are the logs:
I have had over a dozen crashes today because of this.
1 Oct 1 21:25:05 localhost /usr/local/sbin/kamailio[4505]: ERROR: <core> [parser/msg_parser.c:714]: ERROR: parse_msg: message=<<81>É>
2 Oct 1 21:25:05 localhost /usr/local/sbin/kamailio[4505]: ERROR: <core> [receive.c:142]: ERROR: receive_msg: parse_msg failed
3 Oct 1 21:25:05 localhost /usr/local/sbin/kamailio[4494]: ERROR: <core> [parser/msg_parser.c:714]: ERROR: parse_msg: message=<<81>É>
4 Oct 1 21:25:05 localhost /usr/local/sbin/kamailio[4494]: ERROR: <core> [receive.c:142]: ERROR: receive_msg: parse_msg failed
5 Oct 1 21:25:05 localhost /usr/local/sbin/kamailio[4546]: ERROR: <core> [tcp_main.c:4130]: connect xx.xxx.xx.xxx:35524 failed
6 Oct 1 21:25:06 localhost /usr/local/sbin/kamailio[4496]: : <core> [mem/q_malloc.c:156]: BUG: qm_*: prev. fragm. tail overwritten(c0c0c000, abcdefed)[0xabc200:0xabc230]!
7 Oct 1 21:25:06 localhost /usr/local/sbin/kamailio[4546]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 14
8 Oct 1 21:25:06 localhost /usr/local/sbin/kamailio[4493]: ALERT: <core> [main.c:741]: child process 4496 exited by a signal 6
9 Oct 1 21:25:06 localhost /usr/local/sbin/kamailio[4493]: ALERT: <core> [main.c:744]: core was not generated
10 Oct 1 21:25:06 localhost /usr/local/sbin/kamailio[4493]: ERROR: ctl [ctl.c:379]: ERROR: ctl: could not delete unix socket /tmp/ser_ctl: Operation not permitted (1)
11 Oct 1 21:25:06 localhost init: kamailio main process ended, respawning
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=250
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
According to the TM reparse_invite option description Kamailio should
build the CANCEL request from the INVITE message which was sent out
instead of building them from the received request.
And Kamailio does it for all headers except "To".
Kamailio builds "To" header from the received INVITE.
Patch to fix it:
--- ./kamailio-3.2.3/modules/tm/t_cancel.c 2012-08-22
10:39:21.000000000 +0300
+++ ./kamailio-3.2.3-fixed/modules/tm/t_cancel.c 2012-10-01
18:25:57.000000000 +0300
@@ -284,7 +284,7 @@
if (cfg_get(tm, tm_cfg, reparse_invite)) {
/* build the CANCEL from the INVITE which was sent out */
cancel = build_local_reparse(t, branch, &len, CANCEL,
CANCEL_LEN,
- &t->to
+ NULL
#ifdef CANCEL_REASON_SUPPORT
, reason
#endif /* CANCEL_REASON_SUPPORT */
It is not a problem when Kamailio doesn't change "To" header or does it
before transaction creation (t_relay, t_newtran).
To reproduce that situation "To" header should be rewritten in a
branch_route.
build_local_reparse is also used in t_reply.c to build local ACK
requests and passing new "To" header absolutely right there, since "To"
header in ACK must be equal to "To" header field in the response being
acknowledged. But if I correctly understand rfc3261 it is not correct
behaviour for a CANCEL request.
P.S. I've checked 3.3.1 sources and haven't found any changes related to
this issue.
Hi
I created this patch to clean ugly experimental SDP lines.
It is tested with Content-Type multipart/mixed and application/sdp
and body cleaning seem to work fine.
Here is a sample of unwanted SDP attributes that can be filtered with
this function:
---
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 192-194,200-202
a=X-cap: 2 image udptl t38
---
Comments appreciated.
--
Mikko Lehto
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: ",