sr-dev May 2014

sr-dev@lists.kamailio.org

34 participants
238 discussions

[tracker] Task closed: Sometimes some kamailio processes eat 100% CPU

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#434 - Sometimes some kamailio processes eat 100% CPU User who did this - Henning Westerholt (henningw) Reason for closing: Fixed More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=434 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.

10 years, 6 months

[tracker] Comment added: Sometimes some kamailio processes eat 100% CPU

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#434 - Sometimes some kamailio processes eat 100% CPU User who did this - Henning Westerholt (henningw) ---------- Thank you, it was fixed in master and also 4.1 from Daniel. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=434#comment1479 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.

10 years, 6 months

git:master: Merge branch 'master' of ssh://git.sip-router.org/sip-router

by Henning Westerholt

Module: sip-router Branch: master Commit: dc2299c7d19869dc16a66d1b4c6696e204a75e12 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=dc2299c… Author: Henning Westerholt <hw(a)kamailio.org> Committer: Henning Westerholt <hw(a)kamailio.org> Date: Tue May 27 12:17:37 2014 +0200 Merge branch 'master' of ssh://git.sip-router.org/sip-router * 'master' of ssh://git.sip-router.org/sip-router: db_mysql: proper handling of mysql_next_result(...) return code ims_charging: bugfix: Make ims_charging:ccr_timeouts resettable ---

10 years, 6 months

git:master: db_mysql: fixes FS#434, Kamailio will eat sometimes 100% CPU due a bug in db_mysql

by Henning Westerholt

Module: sip-router Branch: master Commit: 0d7d5dc4d7219c5beb9a150cc56e74edac9dc4d5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0d7d5dc… Author: Henning Westerholt <hw(a)kamailio.org> Committer: Henning Westerholt <hw(a)kamailio.org> Date: Tue May 27 12:14:24 2014 +0200 db_mysql: fixes FS#434, Kamailio will eat sometimes 100% CPU due a bug in db_mysql * Fixes FS#434 reported from Maxim, incorrect mysql API usage for mysql_next_result(..) * According MySQL doc, return values for mysql_next_result(..) can be the following: 0 - Successful and there are more results -1 - Successful and there are no more results >0 - An error occured * Thus, if there will be an error when reading a next result, the code will be infinitely looped in “while” cycle and current process will eat 100% CPU (The mysql_more_results will not help here because it just checks a local flag that will be set to TRUE in cases when there will be more than one result). * The solution is to replace " > 0” with " == 0”: --- modules/db_mysql/km_dbase.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/db_mysql/km_dbase.c b/modules/db_mysql/km_dbase.c index cf22e4c..d2ef5c5 100644 --- a/modules/db_mysql/km_dbase.c +++ b/modules/db_mysql/km_dbase.c @@ -258,7 +258,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) db_mysql_free_result(_h, *_r); *_r = 0; #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); } @@ -268,7 +268,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) done: #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); }

10 years, 6 months

git:4.1: db_mysql: proper handling of mysql_next_result(...) return code

by Daniel-Constantin Mierla

Module: sip-router Branch: 4.1 Commit: af4f84b84ca7601bd8124fe2e82d0718c7975313 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=af4f84b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue May 27 12:07:42 2014 +0200 db_mysql: proper handling of mysql_next_result(...) return code - it indicates the presence of another result if return is 0 - reported by Maxim (simax), FS#434 (cherry picked from commit 37f0964278e925d5530563b38c82a57de1f7fa59) --- modules/db_mysql/km_dbase.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/db_mysql/km_dbase.c b/modules/db_mysql/km_dbase.c index a1e7ac7..688d433 100644 --- a/modules/db_mysql/km_dbase.c +++ b/modules/db_mysql/km_dbase.c @@ -197,7 +197,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) db_mysql_free_result(_h, *_r); *_r = 0; #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); } @@ -207,7 +207,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) done: #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); }

10 years, 6 months

git:master: db_mysql: proper handling of mysql_next_result(...) return code

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 37f0964278e925d5530563b38c82a57de1f7fa59 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=37f0964… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue May 27 12:07:42 2014 +0200 db_mysql: proper handling of mysql_next_result(...) return code - it indicates the presence of another result if return is 0 - reported by Maxim (simax), FS#434 --- modules/db_mysql/km_dbase.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/db_mysql/km_dbase.c b/modules/db_mysql/km_dbase.c index cf22e4c..d2ef5c5 100644 --- a/modules/db_mysql/km_dbase.c +++ b/modules/db_mysql/km_dbase.c @@ -258,7 +258,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) db_mysql_free_result(_h, *_r); *_r = 0; #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); } @@ -268,7 +268,7 @@ static int db_mysql_store_result(const db1_con_t* _h, db1_res_t** _r) done: #if (MYSQL_VERSION_ID >= 40100) - while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { + while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); }

10 years, 6 months

git:master: ims_charging: bugfix: Make ims_charging:ccr_timeouts resettable

by Carsten Bock

Module: sip-router Branch: master Commit: 88724f2cc7ca5988713246b3e4d7bfac4612072d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=88724f2… Author: Carsten Bock <carsten(a)ng-voice.com> Committer: Carsten Bock <carsten(a)ng-voice.com> Date: Tue May 27 11:56:32 2014 +0200 ims_charging: bugfix: Make ims_charging:ccr_timeouts resettable --- modules/ims_charging/mod.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules/ims_charging/mod.c b/modules/ims_charging/mod.c index 8de9df7..e305bb5 100644 --- a/modules/ims_charging/mod.c +++ b/modules/ims_charging/mod.c @@ -122,7 +122,7 @@ stat_export_t charging_stats[] = { {"ccr_responses_time", STAT_NO_RESET, &ccr_responses_time}, {"billed_secs", STAT_NO_RESET, &billed_secs}, {"killed_calls", STAT_NO_RESET, &killed_calls}, - {"ccr_timeouts", STAT_NO_RESET, &ccr_timeouts}, + {"ccr_timeouts", 0, &ccr_timeouts}, {0, 0, 0} };

10 years, 6 months

[tracker] Task opened: Sometimes some kamailio processes eat 100% CPU

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Maxim (simax) Attached to Project - sip-router Summary - Sometimes some kamailio processes eat 100% CPU Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Some time ago we had some problems with our MysSQL server and some kamailio processes were got stuck and ate 100% CPU. We use sqlops module to call mysql procedure. The procedure returns two results (a result set and status of the "CALL" command). It seems there is a bug in db_mysql module in file km_dbase.c, function db_mysql_store_result(..). The bug is in incorrect using of MysQL API function mysql_next_result(..). That function is used to skip rest of results returned by DB query (because mysql connection is opened with flag CLIENT_MULTI_STATEMENTS). Part of the code that causes the problem is <code>#if (MYSQL_VERSION_ID >= 40100) while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) > 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); } #endif</code> According MySQL doc, return values for mysql_next_result(..) can be the following: 0 - Successful and there are more results -1 - Successful and there are no more results >0 - An error occured Thus, if there will be an error when reading a next result, the code will be infinitely looped in "while" cycle and current process will eat 100% CPU (The mysql_more_results will not help here because it just checks a local flag that will be set to TRUE in cases when there will be more than one result). The solution is to replace " > 0" with " == 0": <code>#if (MYSQL_VERSION_ID >= 40100) while( mysql_more_results(CON_CONNECTION(_h)) && mysql_next_result(CON_CONNECTION(_h)) == 0 ) { MYSQL_RES *res = mysql_store_result( CON_CONNECTION(_h) ); mysql_free_result(res); } #endif</code> More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=434 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.

10 years, 6 months

Localized docs

by Konstantin M.

Hello, Maybe it is a good idea to have some internationalized docs which will be somewhere near to default lang, e.g. docs/{en_US, ru_RU, ...} ? If so, then how to organize that do have some standard rules to keep the correct docs structure. I'd like to hear your opinion. Thanks!

10 years, 6 months

TM Reply logic

by Jason Penton

Hi, I am confused by the TM reply processing logic in a particular scenario. For example, if an INVITE transaction has had a final reply (let's assume 500 Error in this case). Now, if a 200 OK comes through the proxy to accept the call then according to the code below, the relay will be relayed to the calling party.... why? This will also cause the tm transaction state to change from state 5 (deleted) to state (4) confirmed.... Is this correct? (a result of this scenario is that the A UAC will receive a 500 followed by a 200....) static enum rps t_should_relay_response( struct cell *Trans , int new_code, int branch , int *should_store, int *should_relay, struct cancel_info *cancel_data, struct sip_msg *reply ) { int branch_cnt; int picked_code; int new_branch; int inv_through; int extra_flags; int i; int replies_dropped; /* note: this code never lets replies to CANCEL go through; we generate always a local 200 for CANCEL; 200s are not relayed because it's not an INVITE transaction; >= 300 are not relayed because 200 was already sent out */ DBG("->>>>>>>>> T_code=%d, new_code=%d\n",Trans->uas.status,new_code); inv_through=new_code>=200 && new_code<300 && is_invite(Trans); /* if final response sent out, allow only INVITE 2xx */ if ( Trans->uas.status >= 200 ) { if (inv_through) { DBG("DBG: t_should_relay_response: 200 INV after final sent\n"); *should_store=0; Trans->uac[branch].last_received=new_code; *should_relay=branch; return RPS_PUSHED_AFTER_COMPLETION; } /* except the exception above, too late messages will be discarded */ goto discard; } /* if final response received at this branch, allow only INVITE 2xx */ if (Trans->uac[branch].last_received>=200 && !(inv_through && Trans->uac[branch].last_received<300)) { /* don't report on retransmissions */ if (Trans->uac[branch].last_received==new_code) { DBG("DEBUG: final reply retransmission\n"); goto discard; } /* if you FR-timed-out, faked a local 408 and 487 came or * faked a CANCEL on a non-replied branch don't * report on it either */ if ((Trans->uac[branch].last_received==487) || (Trans->uac[branch].last_received==408 && new_code==487)) { DBG("DEBUG: %d came for a %d branch (ignored)\n", new_code, Trans->uac[branch].last_received); goto discard; } /* this looks however how a very strange status rewrite attempt; * report on it */ LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS: " "stored: %d, received: %d\n", Trans->uac[branch].last_received, new_code ); goto discard; } /* no final response sent yet */

10 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2014