[SR-Users] FW: (Devel) Segmentation fault using pua_dialoginfo

Daniel-Constantin Mierla miconda at gmail.com
Thu May 17 13:51:20 CEST 2012


Hello,

can you print in frame one:

p *ps
p *(ua_pres_t*)(*ps->param)

I wonder why entity is null

Is this a test system where eventually one can get remote access for 
live troubleshooting while you are testing?

Cheers,
Daniel

On 5/16/12 2:02 PM, Charles Chance wrote:
>
> Hi Daniel,
>
> It happens every time but I just can't seem to pinpoint the cause. 
> Those parameters were initially unset and it still happened -- I added 
> them later in an attempt to diagnose.
>
> I removed them and re-ran, which produces a slightly different 
> backtrace...
>
> Program terminated with signal 11, Segmentation fault.
>
> #0  core_hash (t=0xb3dc8e38, type=1024, ps=0xbfcdd5d8) at 
> ../../hashes.h:277
>
> 277 end=s1->s+s1->len;
>
> (gdb) bt
>
> #0  core_hash (t=0xb3dc8e38, type=1024, ps=0xbfcdd5d8) at 
> ../../hashes.h:277
>
> #1  publ_cback_func (t=0xb3dc8e38, type=1024, ps=0xbfcdd5d8) at 
> send_publish.c:246
>
> #2  0x005041d6 in run_trans_callbacks_internal (cb_lst=0xb3dc8e78, 
> type=1024, trans=0xb3dc8e38, params=0xbfcdd5d8) at t_hooks.c:290
>
> #3  0x005044d6 in run_trans_callbacks (type=1024, trans=0x200, 
> req=0x0, rpl=0xb7c30340, code=412) at t_hooks.c:317
>
> #4  0x0052db28 in local_reply (t=0xb3dc8e38, p_msg=0xb7c30340, 
> branch=0, msg_status=412, cancel_data=0xbfcdd86c) at t_reply.c:2001
>
> #5  0x00530b45 in reply_received (p_msg=0xb7c30340) at t_reply.c:2350
>
> #6  0x0809d5f4 in forward_reply (msg=0xb7c30340) at forward.c:790
>
> #7  0x080e11a9 in receive_msg (
>
>     buf=0x82c4fa0 "SIP/2.0 412 Conditional request failed\r\nVia: 
> SIP/2.0/UDP xx.xx.xx.xxx;branch=z9hG4bK7058.f06a8876.0\r\nTo: 
> sip:152 at xx.xx.xx.xxx:5060;tag=03373b1b433b65504ea28bd3d9e6db76.331b\r\nFrom: 
> sip:152 at xx.xx.xx."..., len=374, rcv_info=0xbfcdda58) at receive.c:270
>
> #8  0x0817801b in udp_rcv_loop () at udp_server.c:544
>
> #9  0x080b0426 in main_loop () at main.c:1633
>
> #10 0x080b3d02 in main (argc=11, argv=0xbfcddd34) at main.c:2546
>
> ...although the root cause appears to be the same:
>
> (gdb) frame 0
>
> #0  core_hash (t=0xb3dc8e38, type=1024, ps=0xbfcdd5d8) at 
> ../../hashes.h:277
>
> 277 end=s1->s+s1->len;
>
> (gdb) p *s1
>
> Cannot access memory at address 0x40323531
>
> (gdb) frame 1
>
> #1  publ_cback_func (t=0xb3dc8e38, type=1024, ps=0xbfcdd5d8) at 
> send_publish.c:246
>
> 246 hash_code= core_hash(hentity->pres_uri, NULL, HASH_SIZE);
>
> (gdb) p *hentity
>
> Cannot access memory at address 0x0
>
> The PUBLISH seems to be sent ok for both caller/callee for states 
> trying/confirmed. On tear-down however, it appears to crash somewhere 
> after sending state terminated for the callee as demonstrated by the 
> log...
>
> May 16 11:48:57 ws1 /usr/local/kamailio-devel/sbin/kamailio[31954]: 
> INFO: pua_dialoginfo [dialog_publish.c:386]: CALLING dialog_publish 
> for URI sip:000091 at xx.xx.xx.xxx:5060
>
> May 16 11:48:57 ws1 /usr/local/kamailio-devel/sbin/kamailio[31953]: 
> INFO: pua_dialoginfo [dialog_publish.c:386]: CALLING dialog_publish 
> for URI sip:000091@ xx.xx.xx.xxx:5060
>
> May 16 11:48:57 ws1 /usr/local/kamailio-devel/sbin/kamailio[31953]: 
> INFO: pua_dialoginfo [dialog_publish.c:386]: CALLING dialog_publish 
> for URI sip:152@ xx.xx.xx.xxx:5060
>
> May 16 11:48:57 ws1 /usr/local/kamailio-devel/sbin/kamailio[31953]: 
> INFO: <core> [mem/f_malloc.c:529]: freeing a free fragment 
> (0xb3dc7c18/0xb3dc7c20) - ignore
>
> May 16 11:49:08 ws1 /usr/local/kamailio-devel/sbin/kamailio[31958]: 
> INFO: pua_dialoginfo [dialog_publish.c:386]: CALLING dialog_publish 
> for URI sip:000091@ xx.xx.xx.xxx:5060
>
> May 16 11:49:08 ws1 /usr/local/kamailio-devel/sbin/kamailio[31958]: 
> INFO: pua_dialoginfo [dialog_publish.c:386]: CALLING dialog_publish 
> for URI sip:152@ xx.xx.xx.xxx:5060
>
> May 16 11:49:08 ws1 /usr/local/kamailio-devel/sbin/kamailio[31953]: 
> ERROR: presence [presentity.c:784]: No E_Tag match a.1337165329.31958.1.0
>
> May 16 11:49:09 ws1 /usr/local/kamailio-devel/sbin/kamailio[31941]: 
> ALERT: <core> [main.c:785]: child process 31958 exited by a signal 11
>
> I've attached the records from the presentity table also, as the 
> presence module doesn't appear to be matching the PUBLISHes with 
> existing records.
>
> Thanks again for your time,
>
> Charles
>
> ------------------------------------------------------------------------
>
> *From:*Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> *Sent:* 16 May 2012 08:15
> *To:* Charles Chance
> *Cc:* 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) 
> -Users Mailing List'
> *Subject:* Re: FW: (Devel) Segmentation fault using pua_dialoginfo
>
> Hello,
>
> hmm, hentity is null even a check for its value is done above ...
>
> Is this reproducible or happens from time to time? What are the values 
> you set for $avp(s:puburis_caller) and $avp(s:puburis_callee)?
>
> Can you try without parameters:
>
> modparam("pua_dialoginfo", "use_pubruri_avps", 1)
> modparam("pua_dialoginfo", "pubruri_caller_avp", "$avp(s:puburis_caller)")
> modparam("pua_dialoginfo", "pubruri_callee_avp", "$avp(s:puburis_callee)")
>
> These were added by a recent contribution, I want to see if they are 
> the reason.
>
> Cheers,
> Daniel
>
> On 5/16/12 12:00 AM, Charles Chance wrote:
>
>> Hi Daniel,
>>
>> I tried to check that already, but it's not there:
>>
>> (gdb) frame 1
>>
>> #1  publ_cback_func (t=0xb3d7e330, type=1024, ps=0xbfcc31c8)
>>
>>     at send_publish.c:246
>>
>> 246 hash_code= core_hash(hentity->pres_uri, NULL, HASH_SIZE);
>>
>> (gdb) p *hentity
>>
>> Cannot access memory at address 0x0
>>
>> Config parameters are:
>>
>> modparam("pua", "db_url", "mysql://user:pass@xx.xx.xx.xxx/dbname" 
>> <mailto:mysql://user:pass@xx.xx.xx.xxx/dbname>)
>>
>> modparam("pua", "db_table", "kam_pua")
>>
>> modparam("pua_dialoginfo", "caller_confirmed", 1)
>>
>> modparam("pua_dialoginfo", "include_localremote", 0)
>>
>> modparam("pua_dialoginfo", "override_lifetime", 300)
>>
>> modparam("pua_dialoginfo", "use_pubruri_avps", 1)
>>
>> modparam("pua_dialoginfo", "pubruri_caller_avp", 
>> "$avp(s:puburis_caller)")
>>
>> modparam("pua_dialoginfo", "pubruri_callee_avp", 
>> "$avp(s:puburis_callee)")
>>
>> Cheers,
>>
>> Charles
>>
>> ------------------------------------------------------------------------
>>
>> *From:*Daniel-Constantin Mierla [mailto:miconda at gmail.com]
>> *Sent:* 15 May 2012 21:58
>> *To:* Charles Chance
>> *Cc:* 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) 
>> -Users Mailing List'
>> *Subject:* Re: FW: (Devel) Segmentation fault using pua_dialoginfo
>>
>> Hello,
>>
>> interesting that the output of bt shows inline core_hash function 
>> prototype with same parameters as publ_cback_func, not being able to 
>> spot eventual wrong parameter values.
>>
>> Anyhow, in the gdb, can you do the commands:
>>
>> frame 1
>> p *hentity
>>
>> and send the output? Let's see the value of the pub uri for which 
>> hashing function crashes.
>>
>> What are the parameters for pua and pua_dialog info you set in the 
>> config file?
>>
>> Cheers,
>> Daniel
>>
>> On 5/15/12 11:53 AM, Charles Chance wrote:
>>
>>> Hi Daniel,
>>>
>>> As per your previous reply (sorry, I deleted it accidentally), 
>>> please find attached output of 'bt full' as requested.
>>>
>>> Best regards and thanks again,
>>>
>>> Charles
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:*Charles Chance [mailto:charles.chance at sipcentric.com]
>>> *Sent:* 13 May 2012 11:21
>>> *To:* 'SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) 
>>> -Users Mailing List'
>>> *Subject:* (Devel) Segmentation fault using pua_dialoginfo
>>>
>>> Hi,
>>>
>>> Currently testing devel version and experiencing the following when 
>>> using pua_dialoginfo:
>>>
>>> -------------------------------------
>>>
>>> Program terminated with signal 11, Segmentation fault.
>>>
>>> #0  core_hash (t=0xb3d7e330, type=1024, ps=0xbfcc31c8) at 
>>> ../../hashes.h:279
>>>
>>> 279 v=(*p<<24)+(p[1]<<16)+(p[2]<<8)+p[3];
>>>
>>> (gdb) bt
>>>
>>> #0  core_hash (t=0xb3d7e330, type=1024, ps=0xbfcc31c8) at 
>>> ../../hashes.h:279
>>>
>>> #1  publ_cback_func (t=0xb3d7e330, type=1024, ps=0xbfcc31c8) at 
>>> send_publish.c:246
>>>
>>> #2  0x002861d6 in run_trans_callbacks_internal (cb_lst=0xb3d7e370, 
>>> type=1024, trans=0xb3d7e330, params=0xbfcc31c8) at t_hooks.c:290
>>>
>>> #3  0x002864d6 in run_trans_callbacks (type=1024, trans=0x200, 
>>> req=0x0, rpl=0xb7bea008, code=200) at t_hooks.c:317
>>>
>>> #4  0x002afb28 in local_reply (t=0xb3d7e330, p_msg=0xb7bea008, 
>>> branch=0, msg_status=200, cancel_data=0xbfcc345c) at t_reply.c:2001
>>>
>>> #5  0x002b2b45 in reply_received (p_msg=0xb7bea008) at t_reply.c:2350
>>>
>>> #6  0x0809d5f4 in forward_reply (msg=0xb7bea008) at forward.c:790
>>>
>>> #7  0x080e11a9 in receive_msg (
>>>
>>>     buf=0x82c4fa0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 
>>> xx.xx.xx.xxx;branch=z9hG4bKc13b.25313b6.0\r\nTo: 
>>> sip:000094 at xx.xx.xx.xxx;tag=03373b1b433b65504ea28bd3d9e6db76.d7f2\r\nFrom 
>>> <sip:000094 at xx.xx.xx.xxx;tag=03373b1b433b65504ea28bd3d9e6db76.d7f2%5Cr%5CnFrom>: 
>>> sip:000094 at xx.xx.xx.xxx;tag=4cc17c2c75cb82fa"..., len=393, 
>>> rcv_info=0xbfcc3648) at receive.c:270
>>>
>>> #8  0x0817801b in udp_rcv_loop () at udp_server.c:544
>>>
>>> #9  0x080b0426 in main_loop () at main.c:1633
>>>
>>> #10 0x080b3d02 in main (argc=11, argv=0xbfcc3924) at main.c:2546
>>>
>>> (gdb) up
>>>
>>> #1  publ_cback_func (t=0xb3d7e330, type=1024, ps=0xbfcc31c8) at 
>>> send_publish.c:246
>>>
>>> 246 hash_code= core_hash(hentity->pres_uri, NULL, HASH_SIZE);
>>>
>>> (gdb) p hentity->pres_uri
>>>
>>> Cannot access memory at address 0x8
>>>
>>> (gdb) p *hentity
>>>
>>> Cannot access memory at address 0x0
>>>
>>> -------------------------------------
>>>
>>> Your time is greatly appreciated...
>>>
>>> Charles
>>>
>>
>>
>>
>> -- 
>> Daniel-Constantin Mierla -http://www.asipto.com
>> http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.2171 / Virus Database: 2425/5000 - Release Date: 05/15/12
>>
>
>
> -- 
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda  <http://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2176 / Virus Database: 2425/5001 - Release Date: 05/15/12
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120517/49fabb15/attachment-0001.htm>


More information about the sr-users mailing list