[Kamailio-Users] Core dump on writing dialog profile size into script var.

[Jesus Rodriguez]

Hi Alex,


> I feel retarded asking this as I'm sure it's abundantly made clear on
> the web site / dokuwiki, but what's the SVN URI to check out trunk?


Go to this address (http://www.kamailio.org/mos/view/Download/) and  
search for: "SVN Download"

Saludos
JesusR.





> Daniel-Constantin Mierla wrote:
>
>> Hello Alex,
>>
>> I found a bug in the dialog module, the profile size is integer and  
>> the
>> variable was set as string value. Can you get the trunk and test? I  
>> will
>> backport afterwards, thanks,
>>
>> Daniel
>>
>>
>> On 10/16/08 08:04, Alex Balashov wrote:
>>> It would seem that the malloc for the script var occasionally fails,
>>> which may or may not be central to the issue:
>>>
>>> [SWITCH] Relaying BYE from 210.23.22.23 to sip:2122222322 at 210.23.22.23
>>> (DTAG=706
>>> [SWITCH] [D] No dialog affinity for this BYE
>>> Oct 16 05:03:32 [8710] ERROR:core:set_var_value: out of pkg mem!
>>> Oct 16 05:03:32 [8710] ERROR:dialog:w_get_profile_size: cannot set  
>>> svar
>>> [SWITCH] [D] Profile size for 7709600101 now: 0
>>> [ONREPLY-ROUTE 2] Received 200 for BYE
>>> Relaying INVITE from 210.23.22.23 to sip: 
>>> 2122222322 at 210.23.22.23:5060
>>> [D] Added new dialog for 7709600101
>>> [ONREPLY-ROUTE 1] Provisional reply 100 received.
>>> [ONREPLY-ROUTE 1] 200 OK received for 7709600101
>>> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101
>>> [ONREPLY-ROUTE 1] Dialog profile size is: >
>>> [SWITCH] Relaying ACK from 210.23.22.23 to sip:2122222322 at 210.23.22.23
>>> (DTAG=706
>>> [SWITCH] [D] No dialog affinity for this ACK
>>> Segmentation fault (core dumped)
>>>
>>>
>>> Alex Balashov wrote:
>>>
>>>
>>>> I also have another interesting problem with the aforementioned
>>>> configuration (http://pastebin.com/f28051a5).
>>>>
>>>> When I write the dialog profile size into an AVP, it works fine.
>>>>
>>>> When I write it into a script var, i.e. replace $avp(S:dlg_sz) with
>>>> $var(dlg_sz), it crashes:
>>>>
>>>> Relaying INVITE from 210.23.22.23 to sip:2122222322 at 210.23.22.23:5060
>>>> [D] Added new dialog for 7709600101
>>>> [ONREPLY-ROUTE 1] Provisional reply 100 received.
>>>> [ONREPLY-ROUTE 1] 200 OK received for 7709600101
>>>> [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101
>>>> Segmentation fault (core dumped)
>>>>
>>>> GDB reveals:
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6
>>>> (gdb) where
>>>> #0  0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6
>>>> #1  0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28,
>>>> flags=<value o
>>>>     at script_var.c:122
>>>> #2  0xb7d6c4fe in w_get_profile_size (msg=0x81902b8,
>>>> profile=0xb5ede180 "\034??\
>>>>     value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c: 
>>>> 668
>>>> #3  0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at  
>>>> action.c:850
>>>> #4  0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at
>>>> action.c:138
>>>> #5  0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at  
>>>> action.c:722
>>>> #6  0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at
>>>> action.c:138
>>>> #7  0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at
>>>> action.c:118
>>>> #8  0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c: 
>>>> 1361
>>>> #9  0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507
>>>> #10 0x08090d5b in receive_msg (
>>>>     buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
>>>> 215.22.22.22;branch=z9hG4
>>>> 08.52.173.18\r\nVia: SIP/2.0/UDP
>>>> 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc
>>>> p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203
>>>> #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449
>>>> #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693
>>>>
>>>> It would seem to me that there is some sort of buffer overflow  
>>>> issue
>>>> that results in the garbage seen above.
>>>>
>>>> Not sure that it makes a difference, but the glibc being linked
>>>> against is a Xen-safe one that disables TLS functionality.  This is
>>>> all running inside a Xen DomU.
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
> -- 
> Alex Balashov
> Evariste Systems
> Web    : http://www.evaristesys.com/
> Tel    : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671
> Mobile : (+1) (706) 338-8599
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>





Saludos
JesusR.

------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------