15 Oct
2009
15 Oct
'09
7:37 p.m.
On Oct 15, 2009 at 18:08, marius zbihlei <marius.zbihlei(a)1and1.ro> wrote:
[...]
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.
Ack.
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.
Yes, please patch it.
Another solution is to define cmd_function like in kamailio (haveing 6
(max) numbers of char*)
No, it would be slower for the common cases (more params on the stack or
more registers wasted depending on the arch).
Any suggestions from devs is most welcome. (The problem plagues also
cr_route call with 5 parameters)
A quick grep showed problems only in carrierroute and userblacklist:
carrierroute:
cr_route
cr_prime_route
cr_nofallback_route
userblacklist:
check_user_blacklist
check_user_whitelist
Thanks,
Andrei