Module: sip-router
Branch: master
Commit: b90ac7da0de80d2ce997fc9586976b80e9aee788
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=b90ac7d…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Thu Oct 15 20:06:29 2009 +0200
mi_rpc: Revert Changing mi_rpc licence
Revert commit cbfe9a14fdb05e8212ba4a0b24472f5239850a77
(changing mi_rpc_mod.c licence), at Daniel's request.
---
modules/mi_rpc/mi_rpc_mod.c | 36 ++++++++++--------------------------
1 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/modules/mi_rpc/mi_rpc_mod.c b/modules/mi_rpc/mi_rpc_mod.c
index de9db37..b678f25 100644
--- a/modules/mi_rpc/mi_rpc_mod.c
+++ b/modules/mi_rpc/mi_rpc_mod.c
@@ -5,35 +5,19 @@
*
* Copyright (C) 2009 Daniel-Constantin Mierla (asipto.com).
*
- * This file is part of SIP-router, a free SIP server.
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
*
- * SIP-router is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version
- *
- * SIP-router is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-
- */
-
-/*!
- * \file
- * \brief Management interface :: RPC support
- * \ingroup mi_rpc
- */
-
-/*!
- * \defgroup mi_rpc Management interface :: RPC support
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
Hello,
Bear with me for a second long e-mail
First the Core dump:
Program terminated with signal 11, Segmentation fault.
#0 0x00000020 in ?? ()
(gdb) bt
#0 0x00000020 in ?? ()
#1 0x080bab93 in pv_printf (msg=0xbfdda43c, list=0xbfdda434,
buf=0x820c220 "", len=0xbfdd9f08) at pvapi.c:975
#2 0x080baea7 in pv_printf_s (msg=0x82ac978, list=0xbfdda434,
s=0xbfdd9f04) at pvapi.c:1126
#3 0xb7d27baf in check_user_list (msg=0x82ac978, str1=<value optimized
out>, str2=0x82a977c "\344K*\b", str3=0x0, str4=0xbfdda434 "\200y&\b",
listtype=0)
at userblacklist.c:247
#4 0x0805a424 in do_action (h=0xbfdda698, a=0x82a4a90, msg=0x82ac978)
at action.c:866
#5 0x0805ce28 in run_actions (h=0xbfdda698, a=0x82a4a90, msg=0x82ac978)
at action.c:1301
#6 0x080dd405 in rval_get_int (h=0xbfdda698, msg=0x82ac978,
i=0xbfdda388, rv=0xbfdd9e3c, cache=0x0) at rvalue.c:866
#7 0x080e08ad in rval_expr_eval_int (h=0xbfdda698, msg=0x82ac978,
res=0xbfdda388, rve=0x82a4c94) at rvalue.c:1752
#8 0x080e08d5 in rval_expr_eval_int (h=0xbfdda698, msg=0x82ac978,
res=0xbfdda634, rve=0x82a5048) at rvalue.c:1757
#9 0x08059819 in do_action (h=0xbfdda698, a=0x82a5958, msg=0x82ac978)
at action.c:840
#10 0x0805ce28 in run_actions (h=0xbfdda698, a=0x82a1cd8, msg=0x82ac978)
at action.c:1301
#11 0x0805d184 in run_top_route (a=0x82a1cd8, msg=0x82ac978, c=0x0) at
action.c:1349
#12 0x080c3f1e in receive_msg (
buf=0x8254560 "INVITE sip:49721123456789@127.0.0.1:5059
SIP/2.0\r\nVia: SIP/2.0/UDP
127.0.0.1:5061;branch=z9hG4bK-21468-1-0\r\nFrom: sipp
<sip:sipp@127.0.0.1:5061>;tag=21468SIPpTag001\r\nTo: sut
<sip:49721123456789@127.0."..., len=519, rcv_info=0xbfdda818) at
receive.c:195
#13 0x0814416b in udp_rcv_loop () at udp_server.c:527
#14 0x08098d49 in main_loop () at main.c:1454
#15 0x0809ba98 in main (argc=5, argv=0xbfddaaa4) at main.c:2251
(Check that str4 is not null even if the usage is as below)
How to replicate:
Load userblacklist module (or other kamailio module) and call
check_user_blacklist with 2
parameters(check_user_blacklist("$avp(i:80)", "$avp(i:81)")) (doesn't
work every time, depends on compilation and what pointer lies there)
Problem
The userblacklist module has the exports for the check_user_blacklist :
{ "check_user_blacklist", (cmd_function)check_user_blacklist, 2,
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },
{ "check_user_blacklist", (cmd_function)check_user_blacklist, 3,
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },
{"check_user_blacklist", (cmd_function)check_user_blacklist, 4,
check_user_blacklist_fixup, 0, REQUEST_ROUTE | FAILURE_ROUTE },
The function check_user_blacklist in userblacklist.c has the signature :
int check_user_blacklist(struct sip_msg *msg, char* str1, char* str2,
char* str3, char* str4)
This is cast to a cmd_function (struct sip_msg* msg, char* str1, char*
str2) witch is called with 2 parameters(or casted to cmd_function3 and
called with 3 parameters depending of the case) in the action.c
do_action method. This actually leaves the rest of the pointers having
some random not NULL values, causing the application to crash.
I've seen that sr doesn't use the same function for various number of
parameters. I've made a patch that registered for each number of
parameters an internal function matching the configured number
(
int check_user_blacklist2(struct sip_msg *msg, char* str1, char* str2)
{
return check_user_list(msg, str1, str2, 0, 0, 0);
}
)
. With this everything is ok.
Another solution is to define cmd_function like in kamailio (haveing 6
(max) numbers of char*)
Any suggestions from devs is most welcome. (The problem plagues also
cr_route call with 5 parameters)
P.S.
#0 0xb7d746b2 in actually_rewrite (_msg=0x82b34f4, _carrier=0x82b02f4,
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
_hsrc=shs_call_id, _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:345
345 if (add_avp(AVP_VAL_STR |
descavp->v.pve->spec.pvp.pvn.u.isname.type,
(gdb) bt
#0 0xb7d746b2 in actually_rewrite (_msg=0x82b34f4, _carrier=0x82b02f4,
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
_hsrc=shs_call_id, _halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:345
#1 rewrite_on_rule (_msg=0x82b34f4, _carrier=0x82b02f4,
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
_hsrc=shs_call_id,
_halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:460
#2 rewrite_uri_recursor (_msg=0x82b34f4, _carrier=0x82b02f4,
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
_hsrc=shs_call_id,
_halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:499
#3 cr_do_route (_msg=0x82b34f4, _carrier=0x82b02f4, _domain=0x82b03a4,
_prefix_matching=0x82b034c, _rewrite_user=0x82b03fc, _hsrc=shs_call_id,
_halg=alg_crc32, _dstavp=0x868f2ea) at cr_func.c:591
#4 0xb7d761bf in cr_route (_msg=0x82b34f4, _carrier=0x82b02f4,
_domain=0x82b03a4, _prefix_matching=0x82b034c, _rewrite_user=0x82b03fc,
_hsrc=shs_call_id,
_descavp=0x868f2ea) at cr_func.c:676
#5 0x0805a0aa in do_action (h=0xbf80a0c8, a=0x82a4124, msg=0x82b34f4)
at action.c:917
#6 0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a4124, msg=0x82b34f4)
at action.c:1301
#7 0x080dd405 in rval_get_int (h=0xbf80a0c8, msg=0x82b34f4,
i=0xbf809ad8, rv=0x2e2e2030, cache=0x0) at rvalue.c:866
#8 0x080e08ad in rval_expr_eval_int (h=0xbf80a0c8, msg=0x82b34f4,
res=0xbf809ad8, rve=0x82a4538) at rvalue.c:1752
#9 0x080e08d5 in rval_expr_eval_int (h=0xbf80a0c8, msg=0x82b34f4,
res=0xbf809d84, rve=0x82a48ec) at rvalue.c:1757
#10 0x08059819 in do_action (h=0xbf80a0c8, a=0x82a50a8, msg=0x82b34f4)
at action.c:840
#11 0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a3fd0, msg=0x82b34f4)
at action.c:1301
#12 0x08059872 in do_action (h=0xbf80a0c8, a=0x82a7968, msg=0x82b34f4)
at action.c:855
#13 0x0805ce28 in run_actions (h=0xbf80a0c8, a=0x82a24ac, msg=0x82b34f4)
at action.c:1301
#14 0x0805d184 in run_top_route (a=0x82a24ac, msg=0x82b34f4, c=0x0) at
action.c:1349
#15 0x080c3f1e in receive_msg (
buf=0x8254560 "INVITE sip:49721123456785@127.0.0.1:5060
SIP/2.0\r\nVia: SIP/2.0/UDP
127.0.0.1:5061;branch=z9hG4bK-28495-1-0\r\nFrom: sipp
<sip:sipp@127.0.0.1:5061>;tag=28495SIPpTag001\r\nTo: sut
<sip:49721123456785@127.0."..., len=519, rcv_info=0xbf80a248) at
receive.c:195
#16 0x0814416b in udp_rcv_loop () at udp_server.c:527
#17 0x08098d49 in main_loop () at main.c:1454
#18 0x0809ba98 in main (argc=5, argv=0xbf80a4d4) at main.c:2251
Another core dump by using cr_route without the last avp
i build new sip-router and then tried to make a call, but the request
that sr send out contained binary garbage in the header section after
append_hf call. i have two append_hf calls and garbage is after the
header added by the first call. the second header is not there at all,
but just garbage.
has something changed during the previous couple of days that could
explain this?
-- juha
Module: sip-router
Branch: sr_3.0
Commit: c6e33a080b218ec87184b216144e527cb41754da
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c6e33a0…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Thu Oct 15 17:58:05 2009 +0200
core: fix fixup_spve_* reuse after free
- fixup_spve_* functions have an optimization that checks if a
a parsed format is a simple string and if this happens it frees
the fixed param an re-does the fixup with type==string.
However when freeing the result of the first fixup the original
string was freed too and the next string fixup would be
called with freed memory instead of a valid string.
(this bug was hidden before the memleak fix in af8f3e1536d)
---
mod_fix.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/mod_fix.c b/mod_fix.c
index 90a4a4d..53b12ea 100644
--- a/mod_fix.c
+++ b/mod_fix.c
@@ -197,7 +197,6 @@ FIXUP_F2FP_T(igp_pvar_pvar, 1, 3, 1, FPARAM_INT|FPARAM_PVS, FPARAM_PVS)
int ret; \
char * bkp; \
fparam_t* fp; \
- bkp=*param; \
if (param_no<=(no1)){ \
if ((ret=fix_param_types(FPARAM_PVE, param))<0){ \
ERR("Cannot convert function parameter %d to" #type2 "\n", \
@@ -206,6 +205,8 @@ FIXUP_F2FP_T(igp_pvar_pvar, 1, 3, 1, FPARAM_INT|FPARAM_PVS, FPARAM_PVS)
} else{ \
fp=(fparam_t*)*param; \
if ((ret==0) && (fp->v.pve->spec.getf==0)){ \
+ bkp=fp->orig; \
+ fp->orig=0; /* make sure orig string is not freed */ \
fparam_free_contents(fp); \
pkg_free(fp); \
*param=bkp; \
Hello,
I am wondering whether we are using the right defaults for code
downloaded and compiled from the master branch in the git repository.
I mean the code in that branch is almost always considered unstable
and when people try to compile and use it they mostly do this for
debugging purposes (well, at least developers, ordinary users should
not be using the code).
If you compile the code from the git repository, using compilation
defaults and a very simple configuration file, it is likely that you
end up having lots of memory related messages in syslog and and binary
optimized for speed which can be difficult to debug with gdb.
We have DBG_QM_MALLOC enabled by default in the git repository which I
think is good, however, the value of memdbg is set to L_DBG and the
value of debug is set to L_WARN by default. This means that unless you
explicitly configure memdbg in your configuration file, you'll see all
the memory debugging messages and it is a *a lot* of text.
You can disable memory debugging messages by setting the value of
memdbg higher than debug, but I pretty much always forget to do it.
Also the default configuration files are not consistent in this
regard. The simple one disables it by setting debug to 2 (L_DBG is 3
so memory debugging is disabled), but if you want to investigate a
problem and set debug to 3 to do that then you end up having lots of
traffic in syslog again and you have to use memdbg explicitly in the
configuration file.
The complex one, sip-router-oob.cfg, uses the defaults so you get all
the messages.
How about changing the default for memdbg to a value that is higher
than 3 (the debugging value)? Then we would always have memory
debugging messages disabled and people (both users and developers) can
easily turn them on by configuring a lower value in the configuration
file.
The second default which I believe is not entirely correct for the
code stored in the master branch in the git repository is the
compilation mode. The makefile system generates code that is optimized
for speed by default. We use -O9 which turns on pretty much all
performance optimizations in gcc. That includes variables stored in
CPU registers, however, code that uses such optimizations is difficult
to debug because gdb cannot display values of variables stored in
registers properly.
Here again, I pretty much always forget to add mode=debug when
configuring the build and often have to recompile the code after
trying to use gdb to debug something. Shouldn't we use mode=debug by
default for the code in git master branch?
Or perhaps it is just me having these issues? Maybe others have secret
techniques to share how to avoid such dumb problems?
-- Jan
In a coming commit, I'll introduce two new entities:
+<!ENTITY sercmd "sercmd">
+<!ENTITY ctlsocket "ser_ctl">
These are mentioned in several doc files and will be easier to handle
if we use entities.
/O