sr-dev July 2013

sr-dev@lists.kamailio.org

21 participants
246 discussions

[tracker] Comment added: Possible memory leak in srdb1
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#319 - Possible memory leak in srdb1 User who did this - Konstantin (Konstantin) ---------- I found an example of dynamically allocated column names in db_oracle module (get_columns function in res.c file). ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=319#comment1012 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

[tracker] Task opened: Websocket module leaks tcp connection buffers
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Hugh Waite (hugh.waite) Attached to Project - sip-router Summary - Websocket module leaks tcp connection buffers Task Type - Bug Report Category - tcp Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - The websocket module uses the tcpconn_get function when it needs to lookup the tcp connection from a websocket connection structure. The tcpconn_get function increases to reference count of the connection, and the structure, including the buffer, is not freed while this count is positive. I have tried solve this by adding a tcpconn_put function at the end of each function that did a get, but the system is still leaking buffers. These buffers are not visible in the tcp.dump output because the connection has been closed, but they can be seen in a memory dump (the buffer is 1MB on our system) More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=326 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

[tracker] Comment added: Possible memory leak in srdb1
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#319 - Possible memory leak in srdb1 User who did this - Konstantin (Konstantin) ---------- Yes Daniel, give me time please to find an example. ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=319#comment1011 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

[tracker] Comment added: Possible memory leak in srdb1
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#319 - Possible memory leak in srdb1 User who did this - Daniel-Constantin Mierla (miconda) ---------- Have you read my previous comment? Why you add again the patch? ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=319#comment1010 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

[tracker] Comment added: Possible memory leak in srdb1 (Attachment added)
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#319 - Possible memory leak in srdb1 User who did this - Konstantin (Konstantin) ---------- Please find the fix in the attachment ---------- One or more files have been attached. More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=319#comment1009 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

new features: dns operations in config file
by Daniel-Constantin Mierla 17 Jul '13

17 Jul '13

Hello, I added several functions and a new pseudo-variable class to ipops module that allow to do operations with dns directly from configuration file. One functionality is related to matching an IP address to a hostname. The hostname is resolved via a DNS query and then the IP is matched against the result set. There are two versions of this function, one using the system resolver and the other using the internal dns resolver, see: - http://kamailio.org/docs/modules/devel/modules/ipops.html#ipops.f.dns_sys_m… - http://kamailio.org/docs/modules/devel/modules/ipops.html#ipops.f.dns_int_m… Another enhancement is the possibility to store the result of a system dns query in a variable container and access the values from the config file - the function for the query is dns_query(hostname, pvid): - http://kamailio.org/docs/modules/devel/modules/ipops.html#ipops.f.dns_query The result is stored in $dns(pvid=>key) variable - you can see details about what keys can be used as well as an example at: - http://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#dns_pvid_key_-… The system dns queries use getaddrinfo() C function, resolving both to IPv4 and IPv6. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

[tracker] Comment added: Possible memory leak in srdb1
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#319 - Possible memory leak in srdb1 User who did this - Daniel-Constantin Mierla (miconda) ---------- I checked and the column name is not allocated dynamically by kamailio, but points to a structure to underline db lib. I looked at db_mysql and db_postgres. For example with postgres, the column is set with: /* The pointer that is here returned is part of the result structure. */ RES_NAMES(_r)[col]->s = PQfname(CON_RESULT(_h), col); RES_NAMES(_r)[col]->len = strlen(PQfname(CON_RESULT(_h), col)); Now, looking at postgres lib manual: PQfname - Returns the column name associated with the given column number. Column numbers start at 0. The caller should not free the result directly. It will be freed when the associated PGresult handle is passed to PQclear. Therefore kamailio should not free RES_NAMES(_r)[col]->s. If you think is different, provide more details of how you consider that RES_NAMES(_r)[col]->s is allocated dynamically by kamailio. ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=319#comment1008 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

[tracker] Task closed: force_send_socket() doesnt set the source IP address reliably when using uac_req_send()
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#294 - force_send_socket() doesnt set the source IP address reliably when using uac_req_send() User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Implemented Additional comments about closing: Re-open if not working. More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=294 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

[tracker] Comment added: force_send_socket() doesnt set the source IP address reliably when using uac_req_send()
by sip-router 17 Jul '13

17 Jul '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#294 - force_send_socket() doesnt set the source IP address reliably when using uac_req_send() User who did this - Daniel-Constantin Mierla (miconda) ---------- I committed to master branch an enhancement to be able to set local socket for uac requests. You have to set: $uac_req(sock)= "proto:host:port"; ---------- More information can be found at the following URL: https://sip-router.org/tracker/index.php?do=details&task_id=294#comment1007 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

git:master: core: helper functions to lookup local socket from proto:host: port
by Daniel-Constantin Mierla 17 Jul '13

17 Jul '13

Module: sip-router Branch: master Commit: 6335d07c4c77ed60fb8c2b5acc84d7c4b503221c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6335d07… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Jul 17 12:22:31 2013 +0200 core: helper functions to lookup local socket from proto:host:port --- main.c | 2 +- socket_info.c | 94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ socket_info.h | 10 ++++++ 3 files changed, 105 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 05f45b5..24d3dc8 100644 --- a/main.c +++ b/main.c @@ -924,7 +924,7 @@ error: /* returns -1 on error, 0 on success * sets proto */ -static int parse_proto(unsigned char* s, long len, int* proto) +int parse_proto(unsigned char* s, long len, int* proto) { #define PROTO2UINT3(a, b, c) (( (((unsigned int)(a))<<16)+ \ (((unsigned int)(b))<<8)+ \ diff --git a/socket_info.c b/socket_info.c index b489c8e..3314014 100644 --- a/socket_info.c +++ b/socket_info.c @@ -2057,3 +2057,97 @@ void init_proto_order() } +/** + * parse '[port:]host[:port]' string to a broken down structure + */ +int parse_protohostport(str* ins, sr_phostp_t *r) +{ + char* first; /* first ':' occurrence */ + char* second; /* second ':' occurrence */ + char* p; + int bracket; + char* tmp; + + first=second=0; + bracket=0; + memset(r, 0, sizeof(sr_phostp_t)); + + /* find the first 2 ':', ignoring possible ipv6 addresses + * (substrings between []) + */ + for(p=ins->s; p<ins->s+ins->len; p++){ + switch(*p){ + case '[': + bracket++; + if (bracket>1) goto error_brackets; + break; + case ']': + bracket--; + if (bracket<0) goto error_brackets; + break; + case ':': + if (bracket==0){ + if (first==0) first=p; + else if( second==0) second=p; + else goto error_colons; + } + break; + } + } + if (p==ins->s) return -1; + if (*(p-1)==':') goto error_colons; + + if (first==0) { /* no ':' => only host */ + r->host.s=ins->s; + r->host.len=(int)(p-ins->s); + goto end; + } + if (second) { /* 2 ':' found => check if valid */ + if (parse_proto((unsigned char*)ins->s, first-ins->s, &r->proto)<0) + goto error_proto; + r->port=strtol(second+1, &tmp, 10); + if ((tmp==0)||(*tmp)||(tmp==second+1)) goto error_port; + r->host.s=first+1; + r->host.len=(int)(second-r->host.s); + goto end; + } + /* only 1 ':' found => it's either proto:host or host:port */ + r->port=strtol(first+1, &tmp, 10); + if ((tmp==0)||(*tmp)||(tmp==first+1)){ + /* invalid port => it's proto:host */ + if (parse_proto((unsigned char*)ins->s, first-ins->s, &r->proto)<0) + goto error_proto; + r->host.s=first+1; + r->host.len=(int)(p-r->host.s); + }else{ + /* valid port => its host:port */ + r->host.s=ins->s; + r->host.len=(int)(first-r->host.s); + } +end: + return 0; +error_brackets: + LOG(L_ERR, "too many brackets in %.*s\n", ins->len, ins->s); + return -1; +error_colons: + LOG(L_ERR, "too many colons in %.*s\n", ins->len, ins->s); + return -1; +error_proto: + LOG(L_ERR, "bad protocol in %.*s\n", ins->len, ins->s); + return -1; +error_port: + LOG(L_ERR, "bad port number in %.*s\n", ins->len, ins->s); + return -1; +} + +/** + * lookup a local socket by '[port:]host[:port]' string + */ +struct socket_info* lookup_local_socket(str *phostp) +{ + sr_phostp_t r; + if(parse_protohostport(phostp, &r)<0) + return NULL; + return grep_sock_info(&r.host, (unsigned short)r.port, + (unsigned short)r.proto); +} diff --git a/socket_info.h b/socket_info.h index 926b317..ea0ab8b 100644 --- a/socket_info.h +++ b/socket_info.h @@ -105,6 +105,8 @@ struct socket_info** get_sock_info_list(unsigned short proto); int parse_phostport(char* s, char** host, int* hlen, int* port, int* proto); +int parse_proto(unsigned char* s, long len, int* proto); + char* get_valid_proto_name(unsigned short proto); /* helper function: @@ -142,5 +144,13 @@ inline static struct socket_info* get_first_socket(void) return 0; } +/* structure to break down 'proto:host:port' */ +typedef struct _sr_phostp { + int proto; + str host; + int port; +} sr_phostp_t; + +struct socket_info* lookup_local_socket(str *phostp); #endif

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2013