Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
- list_current->s.s = (char*)( (void*) list_current + sizeof(struct str_list)); + list_current->s.s = (char*)list_current + sizeof(struct str_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid '0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com mailto:0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com http://www.sipcentric.com/
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Thanks, Daniel.
It can be hours, days or weeks between occurrences, but I will report back after a day or two initially then continue to monitor.
Cheers,
Charles On 22 Aug 2014 12:18, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
list_current->s.s = (char*)( (void*) list_current +sizeof(struct str_list));
list_current->s.s = (char*)list_current + sizeof(structstr_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
The patch has tested OK so far.
Regards,
Charles
On 22 August 2014 12:37, Charles Chance charles.chance@sipcentric.com wrote:
Thanks, Daniel.
It can be hours, days or weeks between occurrences, but I will report back after a day or two initially then continue to monitor.
Cheers,
Charles On 22 Aug 2014 12:18, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
list_current->s.s = (char*)( (void*) list_current +sizeof(struct str_list));
list_current->s.s = (char*)list_current + sizeof(structstr_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hey Daniel,
I am puzzled by how this could make any difference? Could you explain? Is this dependent on the compiler used and whether or not void* arithmetic is allowed?
Cheers Jason
On Fri, Aug 22, 2014 at 1:17 PM, Daniel-Constantin Mierla <miconda@gmail.com
wrote:
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
list_current->s.s = (char*)( (void*) list_current +sizeof(struct str_list));
list_current->s.s = (char*)list_current + sizeof(structstr_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
On 28/08/14 20:32, Jason Penton wrote:
Hey Daniel,
I am puzzled by how this could make any difference? Could you explain? Is this dependent on the compiler used and whether or not void* arithmetic is allowed?
void is incomplete type, of no defined data size, you cannot have:
void x;
There is nothing you can assign to x.
An increment of a pointer jumps in memory with the size of its data type (e.g., char* is incremented by 1 byte, int* is incremented by 4 bytes). But for void is mostly unknown behaviour. Based on web, apparently gcc considers sizeof(void) to be 1, but it is not a C standard. Others suggests should be zero (because that's why is a 'void' pointer :-) ).
Maybe Charles can say what compiler he was using.
Cheers, Daniel
Cheers Jason
On Fri, Aug 22, 2014 at 1:17 PM, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello, can you try this small patch? diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) { memset( list_current, 0, len); - list_current->s.s = (char*)( (void*) list_current + sizeof(struct str_list)); + list_current->s.s = (char*)list_current + sizeof(struct str_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len); It is for 4.1. I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1. Cheers, Daniel On 22/08/14 13:03, Charles Chance wrote:Hi All, I wonder if some one could help me to diagnose a recurring issue? It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log: CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid '0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com <mailto:0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com>' and tags 'as77c89620' '' Analysing the core dump reveals: Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24); (gdb) frame 1 #1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) { (gdb) p *ruri $1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275} (gdb) up #2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck); (gdb) p *ruris $2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0} (gdb) up #3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0); (gdb) p *dlginfo->pubruris_caller $3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00} (gdb) p *dlginfo->pubruris_caller->next $4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0} In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly. Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp. Could this be some race condition or something completely different? Thanks in advance, Charles www.sipcentric.com <http://www.sipcentric.com/> Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users-- Daniel-Constantin Mierla http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 -http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users--
*Jason Penton* *Senior Manager: Applications and Services* *Smile Communications Pty (Ltd)* *Mobile:* +27 (0) 83 283 7000 *Skype:* jason.barry.penton
jason.penton@smilecoms.com mailto:name.surname@smilecoms.com www.smilecoms.com http://www.smilecoms.com/
This email is subject to the disclaimer of Smile Communications athttp://www.smilecoms.com/home/email-disclaimer/ http://www.smilecoms.com/home/email-disclaimer/
Yeah, would be cool to see what compiler Charles is using.
Thanks Daniel On 28 Aug 2014 22:25, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
On 28/08/14 20:32, Jason Penton wrote:
Hey Daniel,
I am puzzled by how this could make any difference? Could you explain? Is this dependent on the compiler used and whether or not void* arithmetic is allowed?
void is incomplete type, of no defined data size, you cannot have:
void x;
There is nothing you can assign to x.
An increment of a pointer jumps in memory with the size of its data type (e.g., char* is incremented by 1 byte, int* is incremented by 4 bytes). But for void is mostly unknown behaviour. Based on web, apparently gcc considers sizeof(void) to be 1, but it is not a C standard. Others suggests should be zero (because that's why is a 'void' pointer :-) ).
Maybe Charles can say what compiler he was using.
Cheers, Daniel
Cheers Jason
On Fri, Aug 22, 2014 at 1:17 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
list_current->s.s = (char*)( (void*) list_current +sizeof(struct str_list));
list_current->s.s = (char*)list_current + sizeof(structstr_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton* *Senior Manager: Applications and Services* *SmileCommunications Pty (Ltd)* *Mobile:* +27 (0) 83 283 7000 *Skype:* jason.barry.penton jason.penton@smilecoms.com name.surname@smilecoms.com www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
Hi Both,
In this case the system was using binaries from opensuse build service, so gcc I believe?
Cheers,
Charles On 28 Aug 2014 21:25, "Daniel-Constantin Mierla" miconda@gmail.com wrote:
Hello,
On 28/08/14 20:32, Jason Penton wrote:
Hey Daniel,
I am puzzled by how this could make any difference? Could you explain? Is this dependent on the compiler used and whether or not void* arithmetic is allowed?
void is incomplete type, of no defined data size, you cannot have:
void x;
There is nothing you can assign to x.
An increment of a pointer jumps in memory with the size of its data type (e.g., char* is incremented by 1 byte, int* is incremented by 4 bytes). But for void is mostly unknown behaviour. Based on web, apparently gcc considers sizeof(void) to be 1, but it is not a C standard. Others suggests should be zero (because that's why is a 'void' pointer :-) ).
Maybe Charles can say what compiler he was using.
Cheers, Daniel
Cheers Jason
On Fri, Aug 22, 2014 at 1:17 PM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
can you try this small patch?
diff --git a/modules/pua_dialoginfo/pua_dialoginfo.c b/modules/pua_dialoginfo/pua_dialoginfo.c index 1e88a04..0f02b2b 100644 --- a/modules/pua_dialoginfo/pua_dialoginfo.c +++ b/modules/pua_dialoginfo/pua_dialoginfo.c @@ -347,7 +347,7 @@ struct str_list* get_str_list(unsigned short avp_flags, int_str avp_name) {
memset( list_current, 0, len);
list_current->s.s = (char*)( (void*) list_current +sizeof(struct str_list));
list_current->s.s = (char*)list_current + sizeof(structstr_list); list_current->s.len = avp_value.s.len; memcpy(list_current->s.s,avp_value.s.s,avp_value.s.len);
It is for 4.1.
I have some ongoing work to commit soon on the master branch. if you confirm it is working fine, I will push this patch as well and backport to 4.1.
Cheers, Daniel
On 22/08/14 13:03, Charles Chance wrote:
Hi All,
I wonder if some one could help me to diagnose a recurring issue?
It happens at random times/intervals and under varying load. But always, just before the time of crash, I see the same critical error in log:
CRITICAL: dialog [dlg_hash.c:841]: log_next_state_dlg(): bogus event 6 in state 1 for dlg 0xb0632134 [1367:5814] with clid ' 0695dd7a346188dd24e7520e6c01092c@sip.sipcentric.com' and tags 'as77c89620' ''
Analysing the core dump reveals:
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 128 -M 4 -u kamailio -g kamailio'. Program terminated with signal 11, Segmentation fault. #0 0x081a737c in parse_uri (buf=0x3a70006e <Address 0x3a70006e out of bounds>, len=275, uri=0xbfa2fd2c) at parser/parse_uri.c:389 389 scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);
(gdb) frame 1
#1 0x008fe5dd in dialog_publish (state=0x903f37 "Trying", ruri=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:275 275 if (parse_uri(ruri->s, ruri->len, &ruri_uri) < 0) {
(gdb) p *ruri
$1 = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}
(gdb) up
#2 0x008ff277 in dialog_publish_multi (state=0x903f37 "Trying", ruris=0xb0b5fd00, entity=0xb0632188, peer=0xb0632190, callid=0xb0632180, initiator=1, lifetime=7200, localtag=0x0, remotetag=0x0, localtarget=0x0, remotetarget=0x0, do_pubruri_localcheck=1) at dialog_publish.c:387 387 dialog_publish(state,&(ruris->s),entity,peer,callid,initiator,lifetime,localtag,remotetag,localtarget,remotetarget,do_pubruri_localcheck);
(gdb) p *ruris
$2 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
(gdb) up
#3 0x0090187a in __dialog_created (dlg=0xb0632134, type=2, _params=0x6db064) at pua_dialoginfo.c:470 470 dialog_publish_multi("Trying", dlginfo->pubruris_caller, &(dlg->from_uri), (include_req_uri)?&(dlg->req_uri):&(dlg->to_uri), &(dlg->callid), 1, dlginfo->lifetime, 0, 0, 0, 0, send_publish_flag==-1?1:0);
(gdb) p *dlginfo->pubruris_caller
$3 = {s = {s = 0x31590014 <Address 0x31590014 out of bounds>, len = 275}, next = 0xb0b5fd00}
(gdb) p *dlginfo->pubruris_caller->next
$4 = {s = {s = 0x3a70006e <Address 0x3a70006e out of bounds>, len = 275}, next = 0x0}
In config, for pua_dialoginfo we are enabling the option "use_pubruri_avps" and setting "pubruri_caller_avp" and "pubruri_callee_avp" accordingly.
Therefore, in pua_dialoginfo.c it is using get_str_list() function to set dlginfo->pubruris_caller from the avp.
Could this be some race condition or something completely different?
Thanks in advance,
Charles
www.sipcentric.com
Follow us on twitter @sipcentric http://twitter.com/sipcentric
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
*Jason Penton* *Senior Manager: Applications and Services* *SmileCommunications Pty (Ltd)* *Mobile:* +27 (0) 83 283 7000 *Skype:* jason.barry.penton jason.penton@smilecoms.com name.surname@smilecoms.com www.smilecoms.com
This email is subject to the disclaimer of Smile Communications at http://www.smilecoms.com/home/email-disclaimer/
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Next Kamailio Advanced Trainings 2014 - http://www.asipto.com Sep 22-25, Berlin, Germany ::: Oct 15-17, San Francisco, USA
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-
Charles Chance -
Daniel-Constantin Mierla -
Jason Penton