Re: [SR-Users] Help analysing segmentation fault

Daniel-Constantin Mierla Thu, 28 Aug 2014 13:26:18 -0700

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 gccconsiders sizeof(void) to be 1, but it is not a C standard. Otherssuggests 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<mico...@gmail.com <mailto:mico...@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
    '0695dd7a346188dd24e7520e6c010...@sip.sipcentric.com
    <mailto:0695dd7a346188dd24e7520e6c010...@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.pen...@smilecoms.com <mailto:name.surn...@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/>


--
Daniel-Constantin Mierla
http://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

Re: [SR-Users] Help analysing segmentation fault

Reply via email to