[sr-dev] Fwd: Crash in s-cscf registrar module

Carlos Ruiz Díaz carlos.ruizdiaz at gmail.com
Tue Dec 17 17:05:04 CET 2013


Hi Carsten, Hugh,

Sorry I didn't notice this earlier. Let me check...

Regards,


On Tue, Dec 17, 2013 at 12:38 PM, Carsten Bock <carsten at ng-voice.com> wrote:

> Hi Carlos,
>
> can you check this issue?
>
> Thanks,
> Carsten
>
>
> ---------- Forwarded message ----------
> From: Hugh Waite <hugh.waite at crocodile-rcs.com>
> Date: 2013/12/15
> Subject: [sr-dev] Crash in s-cscf registrar module
> To: Development mailing list of the sip-router project
> <sr-dev at lists.sip-router.org>
>
>
> Hello,
> I am seeing a crash within the latest ims modules using the example
> cfg scripts. It also happened in 4.1
>
> 1) The s-cscf receives a request from an application server and runs
> 'assign_server_unreg' (cfg line 368) because the intended destination
> is not registered.
> 2) The HSS returns an error '5012: Unable to comply' and the suspended
> transaction is resumed into the UNREG_SAR_REPLY route (cxdx_sar.c:290)
> 3) The coredump shows that the AVP lists are nonsensical, so the
> action to get $avp(s:saa_return_code) causes a crash.
>
> Do the avp lists need to be re-initialised from the suspended
> transaction, like in the 'success/done' section (cxdx_sar.c:252)?
> Maybe someone who is more familiar with this code can shine some light on
> this?
>
> Also in this scenario I can't see a code path that will send a
> response back to the application server e.g. '480 Temporarily
> Unavailable' - Should this be done in the cfg before calling
> assign_server_unreg?
>
> Regards,
> Hugh
>
> Backtrace:
>
> (gdb) bt
> #0  0x000000000053dc89 in match_by_name (avp=0x303630363a6d6f63,
> id=116, name=0x7ffff29895f8) at usr_avp.c:391
> #1  0x000000000053e411 in search_next_avp (s=0x7ffff29895f0,
> val=0x7ffff2989630) at usr_avp.c:507
> #2  0x000000000053e120 in search_avp (ident=..., val=0x7ffff2989630,
> state=0x7ffff29895f0) at usr_avp.c:475
> #3  0x000000000053de09 in search_first_avp (flags=1, name=...,
> val=0x7ffff2989630, s=0x7ffff29895f0) at usr_avp.c:427
> #4  0x00007fa8de2f5626 in pv_get_avp (msg=0x7ffff298a030,
> param=0x7fa8de86b898, res=0x7ffff2989760) at pv_core.c:1475
> #5  0x0000000000499270 in pv_get_spec_value (msg=0x7ffff298a030,
> sp=0x7fa8de86b880, value=0x7ffff2989760) at pvapi.c:1266
> #6  0x00000000004c5f03 in rval_get_int (h=0x7ffff2989ef0,
> msg=0x7ffff298a030, i=0x7ffff2989d58, rv=0x7fa8de86b878, cache=0x0) at
> rvalue.c:978
> #7  0x00000000004c89f5 in rval_expr_eval_int (h=0x7ffff2989ef0,
> msg=0x7ffff298a030, res=0x7ffff2989d58, rve=0x7fa8de86b870) at
> rvalue.c:1918
> #8  0x0000000000420648 in do_action (h=0x7ffff2989ef0,
> a=0x7fa8de86eaa8, msg=0x7ffff298a030) at action.c:1219
> #9  0x0000000000422878 in run_actions (h=0x7ffff2989ef0,
> a=0x7fa8de86aa30, msg=0x7ffff298a030) at action.c:1599
> #10 0x0000000000423017 in run_top_route (a=0x7fa8de86aa30,
> msg=0x7ffff298a030, c=0x0) at action.c:1685
> #11 0x00007fa8de59eae3 in t_continue (hash_index=15710,
> label=170389234, route=0x7fa8de86aa30) at t_suspend.c:245
> #12 0x00007fa8da1ebc98 in async_cdp_callback (is_timeout=0,
> param=0x7fa8d5c68f40, saa=0x0, elapsed_msecs=1) at cxdx_sar.c:290
> #13 0x00007fa8db23cacb in api_callback (p=0x7fa8d5c24d40,
> msg=0x7fa8d5c5aca8, ptr=0x0) at api_process.c:115
> #14 0x00007fa8db27ad87 in worker_process (id=2) at worker.c:330
> #15 0x00007fa8db257aea in diameter_peer_start (blocking=0) at
> diameter_peer.c:309
> #16 0x00007fa8db25a02b in cdp_child_init (rank=0) at mod.c:237
> #17 0x00000000004f7ec2 in init_mod_child (m=0x7fa8de841158, rank=0) at
> sr_module.c:924
> #18 0x00000000004f7d65 in init_mod_child (m=0x7fa8de841d00, rank=0) at
> sr_module.c:921
> #19 0x00000000004f7d65 in init_mod_child (m=0x7fa8de8420a8, rank=0) at
> sr_module.c:921
> #20 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842458, rank=0) at
> sr_module.c:921
> #21 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842ae8, rank=0) at
> sr_module.c:921
> #22 0x00000000004f7d65 in init_mod_child (m=0x7fa8de842f60, rank=0) at
> sr_module.c:921
> #23 0x00000000004f8048 in init_child (rank=0) at sr_module.c:948
> #24 0x000000000046d57c in main_loop () at main.c:1694
> #25 0x000000000047030b in main (argc=13, argv=0x7ffff298af78) at
> main.c:2533
>
>
>
> --
> Hugh Waite
> Principal Design Engineer
> Crocodile RCS Ltd.
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
> --
> Carsten Bock
> CEO (Geschäftsführer)
>
> ng-voice GmbH
> Schomburgstr. 80
> D-22767 Hamburg / Germany
>
> http://www.ng-voice.com
> mailto:carsten at ng-voice.com
>
> Office +49 40 34927219
> Fax +49 40 34927220
>
> Sitz der Gesellschaft: Hamburg
> Registergericht: Amtsgericht Hamburg, HRB 120189
> Geschäftsführer: Carsten Bock
> Ust-ID: DE279344284
>
> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
> http://www.ng-voice.com/imprint/
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>



-- 
Carlos
http://caruizdiaz.com
+595981146623
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131217/762701aa/attachment.html>


More information about the sr-dev mailing list