Hi Brett.
I apologize for a error in my last mail. You would not update to 1.4.3, but
you would update to SVN latest stable version 1.4
Best regards.
Sergio.
On 11/11/08, Sergio Gutierrez <[EMAIL PROTECTED]> wrote:
>
> Hi Brett.
>
> Is it difficult to you update to 1.4.3?
>
> As I can see comparing the sources, there are some changes which I think
> fix the crash you are facing.
>
> Regards.
>
> --
> Sergio Gutiérrez
>
> On Tue, Nov 11, 2008 at 5:19 PM, Brett Nemeroff <[EMAIL PROTECTED]>wrote:
>
>> Mostly what I expected: Core was generated by `opensips -Eddddd'.
>> Program terminated with signal 11, Segmentation fault.
>> [New process 7787]
>> #0 do_srv_lookup (name=0x734e20 "_sip._
>> udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292,
>> dn=0x77b2b8) at resolve.c:810
>> 810 else {crt2->next = crt->next;}
>> (gdb) bt
>> #0 do_srv_lookup (name=0x734e20 "_sip._
>> udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292,
>> dn=0x77b2b8) at resolve.c:810
>> #1 0x0000000000455e55 in sip_resolvehost (name=0x7fff3de98e60,
>> port=0x77b292, proto=0x77b294, is_sips=173, dn=0x77b2b8) at resolve.c:1247
>> #2 0x000000000043da45 in mk_proxy (name=0x7fff3de98e60, port=36288,
>> proto=7787, is_sips=0) at proxy.c:252
>> #3 0x00007f59350bac67 in add_uac (t=0x7f5931c99e08, request=0x77eb20,
>> uri=0x7fff3de99100, next_hop=0x7fff3de99110, path=<value optimized out>,
>> proxy=0x0) at ut.h:111
>> #4 0x00007f59350bbed4 in t_forward_nonack (t=0x7f5931c99e08, p_msg=0x0,
>> proxy=0x0) at t_fwd.c:615
>> #5 0x00007f59350b82b1 in t_relay_to (p_msg=0x77eb20, proxy=0x0, flags=0)
>> at t_funcs.c:252
>> #6 0x00007f59350c9bfa in w_t_relay (p_msg=0x77eb20, proxy=0x0, flags=0x0)
>> at tm.c:962
>> #7 0x000000000040f6b7 in do_action (a=0x777568, msg=0x77eb20) at
>> action.c:845
>> #8 0x000000000040e52a in run_action_list (a=<value optimized out>,
>> msg=0x77eb20) at action.c:138
>> #9 0x000000000045fa12 in eval_expr (e=0x777638, msg=0x77eb20,
>> val=0x7799a8) at route.c:1104
>> #10 0x000000000045f6fc in eval_expr (e=0x777680, msg=0x77eb20, val=0x0) at
>> route.c:1417
>> #11 0x000000000045f717 in eval_expr (e=0x7776c8, msg=0x77eb20, val=0x0) at
>> route.c:1422
>> #12 0x000000000040f7ee in do_action (a=0x777870, msg=0x77eb20) at
>> action.c:700
>> #13 0x000000000040e52a in run_action_list (a=<value optimized out>,
>> msg=0x77eb20) at action.c:138
>> #14 0x0000000000410881 in do_action (a=0x776fe8, msg=0x77eb20) at
>> action.c:118
>> #15 0x000000000040e52a in run_action_list (a=<value optimized out>,
>> msg=0x77eb20) at action.c:138
>> #16 0x0000000000411fc0 in run_top_route (a=0x773a70, msg=0x77eb20) at
>> action.c:118
>> #17 0x00000000004506e4 in receive_msg (buf=0x1e6b <Address 0x1e6b out of
>> bounds>, len=1038722304, rcv_info=0x7fff3de9a500) at receive.c:165
>> #18 0x00000000004924d7 in udp_rcv_loop () at udp_server.c:449
>> #19 0x000000000042928f in main (argc=1038722592, argv=0x20) at main.c:780
>>
>>
>> Any thoughts?
>> Thanks,
>> -Brett
>>
>>
>>
>> On Tue, Nov 11, 2008 at 4:16 PM, Brett Nemeroff <[EMAIL PROTECTED]>wrote:
>>
>>> I found it.. thanks.. maybe I'll run gdb on it and see if I can make
>>> anything out of the backtrace..
>>>
>>> Running on Ubuntu 8.04
>>>
>>>
>>> Thanks for your help
>>> -Brett
>>>
>>>
>>> On Tue, Nov 11, 2008 at 4:15 PM, Sergio Gutierrez <[EMAIL PROTECTED]>wrote:
>>>
>>>> Hi Brett.
>>>>
>>>> Is not OpenSER creating a core file when fails? Maybe try to find it at
>>>> /
>>>>
>>>> By the way, what Operating System are you running on?
>>>>
>>>> Check also in OpenSER configuration file to make sure that
>>>> disable_core_dump is set to no.
>>>>
>>>> Regards.
>>>>
>>>> --
>>>> Sergio Gutiérrez
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 11, 2008 at 5:10 PM, Brett Nemeroff <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> Well I definitely see it doing a SRV lookup. When it gets the reply it
>>>>> dies. I'm not really sure how to make it dump core or how to make that
>>>>> available to the developers.
>>>>>
>>>>> The domain I'm using is hosted by Verizon and they control the DNS.
>>>>> Using DIG yields valid SRV records.
>>>>>
>>>>>
>>>>> On Tue, Nov 11, 2008 at 4:06 PM, Sergio Gutierrez <[EMAIL
>>>>> PROTECTED]>wrote:
>>>>>
>>>>>>
>>>>>> Hello Brett.
>>>>>>
>>>>>> If you are trying to use SRV location, I suggest to do it this way:
>>>>>>
>>>>>> rewritehost("wholesaleorigination.acc.globalipcom.com");
>>>>>>
>>>>>> rewriteport("");
>>>>>>
>>>>>> The last line is equivalente to define port as 0, which implies a SRV
>>>>>> lookup.
>>>>>>
>>>>>> Anyway, make sure your DNS defines
>>>>>> wholesaleorigination.acc.globalipcom.com as a SRV RR for SIP.
>>>>>>
>>>>>> Anyway, the issue you reported would be investigated. I suggest to
>>>>>> paste to a backtrace from the corefile, so that developers can trace it.
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> --
>>>>>> Sergio Gutiérrez
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 11, 2008 at 5:02 PM, Brett Nemeroff <[EMAIL PROTECTED]>wrote:
>>>>>>
>>>>>>> It's excessively boring:
>>>>>>>
>>>>>>> main route block........{
>>>>>>> ...
>>>>>>> if ($rU==NULL) {
>>>>>>> # request with no Username in RURI
>>>>>>> sl_send_reply("484","Address Incomplete");
>>>>>>> exit;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> rewritehost("wholesaleorigination.acc.globalipcom.com");
>>>>>>>
>>>>>>>
>>>>>>> route(1);
>>>>>>> exit;
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> route[1] {
>>>>>>> # for INVITEs enable some additional helper routes
>>>>>>> if (is_method("INVITE")) {
>>>>>>> # t_on_branch("2");
>>>>>>> #t_on_reply("2");
>>>>>>> #t_on_failure("1");
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> if (!t_relay()) {
>>>>>>> sl_reply_error();
>>>>>>> };
>>>>>>> exit;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 11, 2008 at 3:56 PM, Sergio Gutierrez <[EMAIL
>>>>>>> PROTECTED]>wrote:
>>>>>>>
>>>>>>>> Hello Brett.
>>>>>>>>
>>>>>>>> could you paste the section of your config file where you are
>>>>>>>> calling rewritehost?
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> Sergio Gutiérrez.
>>>>>>>>
>>>>>>>> On Tue, Nov 11, 2008 at 4:55 PM, Brett Nemeroff <
>>>>>>>> [EMAIL PROTECTED]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi All, I'm using 1.4.2. I'm using rewritehost followed by a
>>>>>>>>> t_relay and I'm getting a crash. Happens every time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Debug log shows:
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out.
>>>>>>>>> buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto
>>>>>>>>> -> do NAPTR lookup!
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(
>>>>>>>>> wholesaleorigination.acc.globalipcom.com, 35) failed
>>>>>>>>> Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR
>>>>>>>>> record found for wholesaleorigination.acc.globalipcom.com, trying
>>>>>>>>> direct SRV lookup...
>>>>>>>>> Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
>>>>>>>>> Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid
>>>>>>>>> 7787 (shutting down?)
>>>>>>>>> Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del
>>>>>>>>> (0x737640, 15, -1, 0x0) fd_no=20 called
>>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787
>>>>>>>>> exited by a signal 11
>>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
>>>>>>>>> Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to
>>>>>>>>> SIGCHLD
>>>>>>>>> Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I know someone else asked this same question, but I never saw a
>>>>>>>>> resolution posted. I do a trace on port 53 at the same time and I most
>>>>>>>>> definately see a SRV record returned:
>>>>>>>>>
>>>>>>>>> 0.000000 192.168.122.250 -> 192.168.122.132 SIP/SDP Request:
>>>>>>>>> INVITE sip:[EMAIL PROTECTED]<[EMAIL PROTECTED]>,
>>>>>>>>> with session description
>>>>>>>>>
>>>>>>>>> 0.016831 192.168.122.132 -> 192.168.122.250 SIP Status: 100
>>>>>>>>> Giving a try
>>>>>>>>>
>>>>>>>>> 0.026370 192.168.122.132 -> 10.128.222.222 DNS Standard query
>>>>>>>>> NAPTR wholesaleorigination.acc.globalipcom.com
>>>>>>>>>
>>>>>>>>> 0.059006 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>>> response
>>>>>>>>>
>>>>>>>>> 0.059087 192.168.122.132 -> 10.128.222.222 DNS Standard query
>>>>>>>>> NAPTR wholesaleorigination.acc.globalipcom.com.sipinterchange.com
>>>>>>>>>
>>>>>>>>> 0.091265 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>>> response, No such name
>>>>>>>>>
>>>>>>>>> 0.091332 192.168.122.132 -> 10.128.222.222 DNS Standard query
>>>>>>>>> SRV _sip._udp.wholesaleorigination.acc.globalipcom.com
>>>>>>>>>
>>>>>>>>> 0.126236 10.128.222.222 -> 192.168.122.132 DNS Standard query
>>>>>>>>> response SRV 100 50 5060 wholesaleoriginationc.acc.globalipcom.comSRV
>>>>>>>>> 100 50 5060
>>>>>>>>> wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060
>>>>>>>>> wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060
>>>>>>>>> wholesaleoriginationb.acc.globalipcom.com
>>>>>>>>>
>>>>>>>>> 8 packets captured
>>>>>>>>> (the packet capture doesn't return anything else past this because
>>>>>>>>> opensips is dead)
>>>>>>>>>
>>>>>>>>> Any ideas?
>>>>>>>>> Thanks,
>>>>>>>>> Brett
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Users mailing list
>>>>>>>>> Users@lists.opensips.org
>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
> --
> Sergio Gutiérrez
>
--
Sergio Gutiérrez
--
Sergio Gutiérrez
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
