[OpenSIPS-Users] SRV lookup causes OpenSIPS to exit signal 11

Jeff Pyle jpyle at fidelityvoice.com
Thu Oct 16 20:16:45 CEST 2008


Hi Bogdan,

1.4 looks good.  No more crashy crashy.  Well done.



- Jeff
 

-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro] 
Sent: Thursday, October 16, 2008 9:35 AM
To: Jeff Pyle
Cc: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] SRV lookup causes OpenSIPS to exit signal
11

Jeff,

Somebody else already validated the fix, so it was backported to 1.4. Of
course, I still wait for a validation from your side.

Regards,
Bogdan

Bogdan-Andrei Iancu wrote:
> Jeff,
>
> There is a fix available on the SVN trunk (not yet ported to 1.4 as I 
> want to be 100% sure it works). Could you please update and test
again?
>
> Regards,
> Bogdan
>
> Bogdan-Andrei Iancu wrote:
>> Hi Jeff,
>>
>> You got it - let me dig a bit though the code - please do not remove 
>> the core, I might need some extra info in.
>>
>> Regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>>> Bogdan,
>>>
>>> I think I figured it out.  Let me know if this is what you're 
>>> looking
>>> for:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> do_srv_lookup (name=0x8166620 "_sip._udp.ns.onvoip.net", 
>>> port=0x81c05ae,
>>> dn=0x81c05c8) at resolve.c:810
>>> 810                        else {crt2->next =
>>> crt->next;}
>>> (gdb) bt
>>> #0  do_srv_lookup (name=0x8166620 "_sip._udp.ns.onvoip.net", 
>>> port=0x81c05ae, dn=0x81c05c8) at resolve.c:810
>>> #1  0x08099f42 in sip_resolvehost (name=0xbff8268c, port=0x81c05ae, 
>>> proto=0x81c05b0, is_sips=0, dn=0x81c05c8)
>>>     at resolve.c:1247
>>> #2  0x080820c6 in mk_proxy (name=0xbff8268c, port=0, proto=0,
>>> is_sips=0)
>>> at proxy.c:252
>>> #3  0x0012fbb4 in add_uac (t=0xb6119a40, request=0x81bfc98,
>>> uri=0xbff82858, next_hop=0xbff82860, path=0x81bffb4,     proxy=0x0) 
>>> at ut.h:111
>>> #4  0x001307eb in t_forward_nonack (t=0xb6119a40, p_msg=0x81bfc98,
>>> proxy=0x0) at t_fwd.c:615
>>> #5  0x0012c7b4 in t_relay_to (p_msg=0x81bfc98, proxy=0x0, 
>>> flags=<value optimized out>) at t_funcs.c:252
>>> #6  0x0013f5b1 in w_t_relay (p_msg=0x81bfc98, proxy=0x0, flags=0x2 
>>> <Address 0x2 out of bounds>) at tm.c:962
>>> #7  0x08052fa6 in do_action (a=0x81b0b40, msg=0x81bfc98) at
>>> action.c:845
>>> #8  0x08055819 in run_action_list (a=0x81b0b40, msg=0x81bfc98) at
>>> action.c:138
>>> #9  0x080a4724 in eval_expr (e=0x81b0ba8, msg=0x81bfc98, val=0x0) at
>>> route.c:1104
>>> #10 0x080a419f in eval_expr (e=0x81b0bd0, msg=0x81bfc98, val=0x0) at
>>> route.c:1417
>>> #11 0x080a4135 in eval_expr (e=0x81b0bf8, msg=0x81bfc98, val=0x0) at
>>> route.c:1422
>>> #12 0x08052a87 in do_action (a=0x81b0d10, msg=0x81bfc98) at 
>>> action.c:700
>>> #13 0x08055819 in run_action_list (a=0x81afb90, msg=0x81bfc98) at
>>> action.c:138
>>> #14 0x08054088 in do_action (a=0x81b3958, msg=0x81bfc98) at
>>> action.c:118
>>> #15 0x08055819 in run_action_list (a=0x81b0f78, msg=0x81bfc98) at
>>> action.c:138
>>> #16 0x08054088 in do_action (a=0x81aee50, msg=0x81bfc98) at
>>> action.c:118
>>> #17 0x08055819 in run_action_list (a=0x81aede8, msg=0x81bfc98) at
>>> action.c:138
>>> #18 0x080544c5 in do_action (a=0x81aeeb8, msg=0x81bfc98) at
>>> action.c:717
>>> #19 0x08055819 in run_action_list (a=0x81aab00, msg=0x81bfc98) at
>>> action.c:138
>>> #20 0x08055bb3 in run_top_route (a=0x81aab00, msg=0x81bfc98) at
>>> action.c:118
>>> #21 0x08094f59 in receive_msg (
>>>     buf=0x81790a0 "INVITE 
>>> sip:3032391067 at dproxy2.sip.fidelityvoice.com
>>> SIP/2.0\r\nVia: SIP/2.0/UDP
>>> 207.58.201.66:5060;branch=z9hG4bK08abb726;rport\r\nFrom: \"Jeff
Pyle\"
>>> <sip:2162454106 at 207.58.201.66>;tag=as4af3b8bf\r\nTo: <sip"...,     
>>> len=915, rcv_info=0xbff83c34) at receive.c:165
>>> #22 0x080d7ab7 in udp_rcv_loop () at udp_server.c:449
>>> #23 0x0806d5ce in main (argc=1, argv=0xbff83e24) at main.c:780
>>>
>>>
>>> - Jeff
>>>
>>>
>>> -----Original Message-----
>>> From: Bogdan-Andrei Iancu [mailto:bogdan at voice-system.ro] Sent: 
>>> Wednesday, October 15, 2008 6:10 AM
>>> To: Jeff Pyle
>>> Cc: users at lists.opensips.org
>>> Subject: Re: [OpenSIPS-Users] SRV lookup causes OpenSIPS to exit 
>>> signal
>>> 11
>>>
>>> Hi Jeff,
>>>
>>> do you have a backtrace or something? maybe the guilty code the new 
>>> SRV balancer that was introduced in 1.4.0 ....and it is alpha code.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Jeff Pyle wrote:
>>>  
>>>> Hello,
>>>>  
>>>> I'm running OpenSIPS from the opensips_1_4 trunk on SVN (downloaded

>>>> last week).  It seems that about 50% of the time an SRV lookup 
>>>> causes OpenSIPS to exit signal 11:
>>>>  
>>>> DBG:core:sip_resolvehost: no valid NAPTR record found for 
>>>> ns.onvoip.net, trying direct SRV lookup...
>>>> INFO:core:handle_sigs: child process 19363 exited by a signal 11 
>>>> When it does not fail, this section of the log looks like:
>>>>  
>>>> DBG:core:sip_resolvehost: no valid NAPTR record found for 
>>>> ns.onvoip.net, trying direct SRV lookup...
>>>> DBG:core:do_srv_lookup: SRV(_sip._udp.ns.onvoip.net) = 
>>>> ns3.onvoip.net:5060
>>>> DBG:core:a2dns_node: storing ns4.onvoip.net:5060
>>>> DBG:core:a2dns_node: storing ns1.onvoip.net:5060
>>>> DBG:core:a2dns_node: storing ns2.onvoip.net:5060 Everything prior 
>>>> to this in the logs is identical between the successful and failed 
>>>> transactions.  Even at debug = 9.
>>>>  
>>>> The location table has the following information on the user:
>>>>  
>>>>            id: 6
>>>>       groupid: 0
>>>>      username: 3032391067
>>>>        domain:
>>>>       contact: sip:3032391067 at ns.onvoip.net
>>>>      received: NULL
>>>>          path: NULL
>>>>       expires: 2020-05-28 21:32:15
>>>>             q: 1.00
>>>>        callid: Default-Call-ID
>>>>          cseq: 13
>>>> last_modified: 2008-04-22 16:25:11
>>>>         flags: 0
>>>>        cflags: 0
>>>>    user_agent:
>>>>        socket: NULL
>>>>       methods: NULL
>>>> I manually inserted this into the database.  It did not come from a

>>>> registration.
>>>>  
>>>> The route logic is quite simple.  I have:
>>>>  
>>>>         if (!lookup("location")) {
>>>>                 # Stuff that doesn't matter because the lookup was 
>>>> successful in this case
>>>>         }
>>>>         t_on_reply("1");
>>>>         t_on_failure("1");
>>>>         if (!isflagset(26)) {
>>>>                 $(avp(s:acc_callee_user)) = $rU;
>>>>                 avp_printf("$(avp(i:901))",
>>>>     
>>> "$(avp(s:acc_caller_user))");
>>>  
>>>>                 avp_printf("$(avp(i:902))",
>>>>     
>>> "$(avp(s:acc_callee_user))");
>>>  
>>>>         }
>>>>  
>>>>         if(is_present_hf("Proxy-Authorization")) { 
>>>> remove_hf("Proxy-Authorization"); }
>>>>  
>>>>         xlog("L_INFO", "-- About to relay...\n");
>>>>         if(!t_relay("0x01")) {
>>>>                 sl_reply_error();
>>>>         }
>>>>         exit;
>>>> Very similar code works okay on OpenSER 1.3.2.  On OpenSIPS 1.4.x 
>>>> it does not seem stable.  I don't know how to determine what's 
>>>> causing it
>>>>     
>>>
>>>  
>>>> to exit.  Any thoughts?
>>>>  
>>>> Thanks,
>>>> Jeff
>>>>  
>>>>  
>>>>
>>>> -------------------------------------------------------------------
>>>> ---
>>>> --
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>     
>>>
>>>
>>>   
>>
>>
>
>




More information about the Users mailing list