[sr-dev] Crash in s-cscf registrar module
Carsten Bock
carsten at ng-voice.com
Wed Dec 18 18:10:13 CET 2013
Hi Hugh,
did the patch work for you? If yes, we would commit the changes to GIT.
Thanks for testing,
Carsten
2013/12/17 Carlos Ruiz Díaz <carlos.ruizdiaz at gmail.com>:
> Hi Hugh,
>
> that is indeed the problem, and I noticed this pattern in similar modules.
>
> I remember having this issue with the ims_charging module which I patched
> for enhancements and that works in a similar fashion regarding the
> suspension and resuming of transactions.
>
> For error conditions, we might have the return code unset, causing the crash
> you described. To avoid that , I imported the transaction AVP list right
> after the transaction lookup and before checking for any kind of errors.
> Also, I always set the AVP to a known value whether there was an error or
> not. Attached I provide you a patch (which I haven't tested but) that will
> hopefully cover all possible scenarios, could you please try it?
>
> Regarding the null string when printing the AVP from configuration file, I
> think this is an interpolation problem due to the fact that the AVP is
> actually numeric and not alphanumeric. If you check the function that
> creates the AVP, you will notice AVP_NAME_STR as the type. I also changed
> this in the ims_charging module and here's the function that I used instead
> [1].
>
> [1] https://gist.github.com/caruizdiaz/8008968
>
> Regards,
>
>
> On Tue, Dec 17, 2013 at 2:12 PM, Hugh Waite <hugh.waite at crocodile-rcs.com>
> wrote:
>>
>> Hi Carlos, Carsten,
>> From a bit of code inspection, it looks like this affects the error paths
>> for the diameter responses.
>> I've seen these warnings printed from both the s-cscf, and the i-cscf when
>> there were diameter timeouts (although it didn't cause a crash every time).
>>
>> Dec 15 12:13:23 kamailio kam-scscf[22542]: ERROR: <script>: We need to do
>> an UNREG server SAR assignemnt
>> Dec 15 12:13:23 kamailio kam-scscf[22542]: INFO: ims_registrar_scscf
>> [cxdx_sar.c:79]: create_return_code(): created AVP successfully :
>> [saa_return_code] - [-2]
>> Dec 15 12:13:23 kamailio kam-scscf[22553]: INFO: ims_registrar_scscf
>> [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed
>> finding avp
>> Dec 15 12:13:23 kamailio kam-scscf[22553]: INFO: ims_registrar_scscf
>> [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_charging_info: Failed finding avp
>> Dec 15 12:13:23 kamailio kam-scscf[22553]: ERROR: <script>: Unknown return
>> code from SAR, value is [<null>]
>> ...
>> Dec 16 17:53:51 kamailio kam-icscf[23653]: INFO: ims_icscf
>> [cxdx_uar.c:71]: create_uaa_return_code(): created AVP successfully :
>> [uaa_return_code]
>> Dec 16 17:53:57 kamailio kam-icscf[23666]: ERROR: ims_icscf
>> [cxdx_uar.c:107]: async_cdp_uar_callback(): Error timeout when sending
>> message via CDP
>> Dec 16 17:53:57 kamailio kam-icscf[23666]: ERROR: <script>: Unknown return
>> code from UAR, value is [<null>]
>>
>> I think there are two issues:
>> 1) The return_code avp does not work causing a NULL value or crash. I
>> experimented by restoring the avp lists from the suspended transaction in
>> the 'error:' section and this seems to work (attached patch) - I can now see
>> the "-2" return code that was set up before the suspend. I'll leave it to
>> you or others to decide if the error handling is being done properly in this
>> function and if my patch is useful.
>>
>> Dec 17 16:41:07 kamailio kam-scscf[25089]: ERROR: <script>: We need to do
>> an UNREG server SAR assignemnt
>> Dec 17 16:41:07 kamailio kam-scscf[25089]: INFO: ims_registrar_scscf
>> [cxdx_sar.c:79]: create_return_code(): created AVP successfully :
>> [saa_return_code] - [-2]
>> Dec 17 16:41:07 kamailio kam-scscf[25099]: INFO: ims_registrar_scscf
>> [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed
>> finding avp
>> Dec 17 16:41:07 kamailio kam-scscf[25099]: INFO: ims_registrar_scscf
>> [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_charging_info: Failed finding avp
>> Dec 17 16:41:07 kamailio kam-scscf[25099]: ERROR: <script>: SAR error -
>> error response sent from module
>>
>> 2) In these error cases, the original transaction is not responded to.
>> This leaves hanging calls and other requests. Perhaps the example cfgs could
>> be updated with default replies in the appropriate places.
>>
>> Let me know if there are patches you want me to try.
>>
>> Hugh
>>
>>
>> On 15/12/2013 21:17, Hugh Waite wrote:
>>
>> 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
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Carlos
> http://caruizdiaz.com
> +595981146623
>
> _______________________________________________
> 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/
More information about the sr-dev
mailing list