sr-dev November 2014

sr-dev@lists.kamailio.org

38 participants
207 discussions

git:master: htable: make locking to access a slot re-entrant for a process
by Daniel-Constantin Mierla 08 Nov '14

08 Nov '14

Module: sip-router Branch: master Commit: 4f07daab9cb95e13c7c89a9a566d4a8c88b9145e URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4f07daa… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Nov 8 10:57:00 2014 +0100 htable: make locking to access a slot re-entrant for a process - proper functionality for sht_lock()/sht_unlock() --- modules/htable/ht_api.c | 119 +++++++++++++++++++++++++++++----------------- modules/htable/ht_api.h | 11 +++- modules/htable/ht_db.c | 3 +- modules/htable/htable.c | 38 ++++++++-------- 4 files changed, 104 insertions(+), 67 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=4f0…

1 0

git:master: htable: use mode everywhere to control the locks for add operation
by Daniel-Constantin Mierla 08 Nov '14

08 Nov '14

Module: sip-router Branch: master Commit: c7ff8a88e773e8d25958f86d178f05ee10fd0410 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c7ff8a8… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Nov 6 18:43:50 2014 +0100 htable: use mode everywhere to control the locks for add operation --- modules/htable/ht_api.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/modules/htable/ht_api.c b/modules/htable/ht_api.c index 13d373d..55f1f3a 100644 --- a/modules/htable/ht_api.c +++ b/modules/htable/ht_api.c @@ -606,7 +606,7 @@ ht_cell_t* ht_cell_value_add(ht_t *ht, str *name, int val, int mode, if(it->next) it->next->prev = it->prev; ht->entries[idx].esize--; - lock_release(&ht->entries[idx].lock); + if(mode) lock_release(&ht->entries[idx].lock); ht_cell_free(it); return NULL; } @@ -625,7 +625,7 @@ ht_cell_t* ht_cell_value_add(ht_t *ht, str *name, int val, int mode, if(old->msize>=it->msize) { memcpy(old, it, it->msize); - lock_release(&ht->entries[idx].lock); + if(mode) lock_release(&ht->entries[idx].lock); return old; } } @@ -673,7 +673,7 @@ ht_cell_t* ht_cell_value_add(ht_t *ht, str *name, int val, int mode, if(old->msize>=it->msize) { memcpy(old, it, it->msize); - lock_release(&ht->entries[idx].lock); + if(mode) lock_release(&ht->entries[idx].lock); return old; } }

1 0

[tracker] Comment added: htable sht_lock problem
by sip-router 07 Nov '14

07 Nov '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#490 - htable sht_lock problem User who did this - Daniel-Constantin Mierla (miconda) ---------- It is indeed ending in a deadlock. I will see what can be done as soon as I get some time for it. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=490#comment1688 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.

1 0

kamailio 4.1.6 (x86_64/linux) 010d57 Crash
by Kristian Kielhofner 07 Nov '14

07 Nov '14

Hello, We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached). #0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547 Any thoughts? Thanks! -- Kristian Kielhofner

3 5

[tracker] Comment added: crash in dns_cache.c when using natping
by sip-router 07 Nov '14

07 Nov '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#491 - crash in dns_cache.c when using natping User who did this - Daniel-Constantin Mierla (miconda) ---------- The nathelper has to indicate the proto -- if it doesn't want a specific one, it has to be PROTO_NONE. I think this is what is used over the rest of the code. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=491#comment1687 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.

1 0

Fwd: Re: Is there a sense in calling run_onsend() after the msg_send() function?
by Lucian Balaceanu 07 Nov '14

07 Nov '14

Hi Daniel, Indeed the case with the state full replies seems not to be taken care of. I attach a patch with the proposed solution. Could you please provide feedback? 1. I am unsure if the place I introduced the run_onsend call is appropriate since the buf used for msg_send is constructed build_res_buf_from_sip_req and build_res_buf_from_sip_res calls. 2. Also, we can maybe unite these if call branches I created: send_res = msg_send(&uas_rb->dst, buf, res_len); send_res = SEND_PR_BUFFER( uas_rb, buf, res_len ); 3. Do you think a get_send_socket snippet as follows should be inserted before the /*if (onsend_route_enabled(SIP_REPLY)){*/ : if(dst.send_sock == NULL) { dst.send_sock=get_send_socket(msg, &dst.to, dst.proto); if (dst.send_sock==0){ LM_ERR("cannot forward reply\n"); } } Thank you, Lucian On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote: > Hello Lucian, > > I applied your patch with some fixes. > > I haven't checked with stateful replies, at some point a function from > core should be used. You can go ahead and see if it works, if not, let > me know and I can look into it as well. You can follow the callbacks > for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they > should lead to the place where a sip response is going to be sent out. > > Cheers, > Daniel > > On 27/10/14 12:51, Lucian Balaceanu wrote: >> Hello Daniel, >> >> I must admit I only saw your mail last Friday. Until the 10th of >> October I was also on vacation. I know that you actually committed >> some of the changes together with your comments on the 12th this month. >> >> I don't know if we can consider the topic of the patch closed. As far >> as I understand, the state-full replies have not been addressed, >> right? (There should be a change in the t_reply.c) I followed the >> code to the relay_reply but I did not yet come to find the send >> function. Should I pursue further? >> >> Thank you, >> Lucian Balaceanu >> >>> Hi Lucian, >>> >>> somehow I forgot to follow up on this. But we need to get sorted out >>> soon, before we release, so it works as expected with the new >>> version. See more comments inline. >>> >>> >>> On 17/09/14 18:09, Lucian Balaceanu wrote: >>>> Hi Daniel, >>>> >>>> Please forgive me for my delay in responding to your mail. >>>> Please find attached a second version of the onsend_route_reply >>>> patch (which again has some problems). As per your previous >>>> indications I did the following: >>>> >>>> *Issue1* >>>>> From performances point of view, there can be added a config >>>>> parameter to enable running of onsend_route for replies: >>>>> >>>>> onsend_route_reply = 0|1 >>>> >>>> Following >>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I >>>> have tried to add onsend_route_reply parameter. The code compiles, >>>> but when trying to start kamailio with this parameter inside, the >>>> parsing fails with syntax errors signaling: >>>> >>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: syntax error >>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config >>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >>>> column 0: >>>> ERROR: bad config file (2 errors)/ >>> >>> The issue is: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return NUMBER; } >>> >>> It should be: >>> >>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); >>> + yy_number_str=yytext; return ONSEND_RT_REPLY; } >>> >>>> >>>> *Issue2* >>>>> #define onsend_enabled(rtype) >>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0) >>>> That is to say you see it best to take the chek for >>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and >>>> call this onsend_enabled(...) before the run_onsend()? >>> >>> This is to detect whether the onsend_route should be executed for >>> SIP replies. The condition being: >>> >>> - if is a sip reply and onsend_route is set and the >>> onsend_route_reply parameter is 1 >>>> >>>> *Issue3* >>>>> On the other hand, is onsend_route also executed for local >>>>> requests? I had in mind it is only for received requests that are >>>>> forwarded ... Iirc, on onsend_route, the sip message is the one >>>>> received, the outgoing content being accessible via $snd(buf). >>>>> >>>> I agree with you with taking out the locally generated requests and >>>> only left the run_onsend call in do_forward_reply function (inside >>>> forward.c). >>>> Could you point me to the reply relaying function that is called >>>> for state-full processing? >>> Stateful processing for replies is mainly done in t_reply.c from tm >>> module. At some point there should be a send buffer function call. >>> >>> Cheers, >>> Daniel >>>> >>>> Thank you and sorry again for my late answer, >>>> Lucian >>> >>> -- >>> Daniel-Constantin Mierla >>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda >>> >>> >> > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

1 0

git:refs/tags/4.0.7: Tag 4.0.7: 4.0.7
by Daniel-Constantin Mierla 07 Nov '14

07 Nov '14

Module: sip-router Branch: refs/tags/4.0.7 Tag: 67815f90d82656dfaf9f9169092ea25b39cf41ed URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=tag;h=67815f90d8… Tagger: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Nov 7 14:46:45 2014 +0100 4.0.7

1 0

Kamailio v4.0.7 Released
by Daniel-Constantin Mierla 07 Nov '14

07 Nov '14

Hello, Kamailio SIP Server v4.0.7 stable release is out. This is a maintenance release of the 3rd old stable branch, 4.0, that includes fixes since release of v4.0.6. There is no change to database schema or configuration language structure that you have to do on installations of v4.0.x. Deployments running previous v4.0.x versions are strongly recommended to be upgraded to v4.0.7, or even better, to 4.1.x or 4.2.x, as the focus from now on will be on maintenance of these release series. For more details about version 4.0.7 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2014/11/kamailio-v4-0-7-released/ Note: the latest stable branch is 4.2, at this moment with its latest release v4.2.0. See more details about it at: * http://www.kamailio.org/w/2014/10/kamailio-v4-2-0-released/ Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

git:4.0: ChangeLog: content updated for v4.0.7
by Daniel-Constantin Mierla 07 Nov '14

07 Nov '14

Module: sip-router Branch: 4.0 Commit: 6376a59aa7767580d80598165f56e2878da35d6a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6376a59… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Nov 7 12:55:18 2014 +0100 ChangeLog: content updated for v4.0.7 --- ChangeLog | 2172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 2172 insertions(+), 0 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=637…

1 0

git:4.0: Makefile.defs: version set to 4.0.7
by Daniel-Constantin Mierla 07 Nov '14

07 Nov '14

Module: sip-router Branch: 4.0 Commit: 5bc523134c66b0f323a9ff3e19b41145f55defa2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5bc5231… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Nov 7 12:47:33 2014 +0100 Makefile.defs: version set to 4.0.7 --- Makefile.defs | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.defs b/Makefile.defs index eee4038..dfb9f01 100644 --- a/Makefile.defs +++ b/Makefile.defs @@ -162,7 +162,7 @@ INSTALL_FLAVOUR=$(FLAVOUR) #version number VERSION = 4 PATCHLEVEL = 0 -SUBLEVEL = 6 +SUBLEVEL = 7 EXTRAVERSION = # memory manager switcher

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
21
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2014