<div dir="ltr">Hi Hugh,<div><br></div><div>that is indeed the problem, and I noticed this pattern in similar modules. </div><div><br></div><div>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. </div>
<div><br></div><div>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?</div>
<div><br></div><div>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].</div>
<div><br></div><div>[1] <a href="https://gist.github.com/caruizdiaz/8008968">https://gist.github.com/caruizdiaz/8008968</a></div><div><br></div><div>Regards,</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Dec 17, 2013 at 2:12 PM, Hugh Waite <span dir="ltr"><<a href="mailto:hugh.waite@crocodile-rcs.com" target="_blank">hugh.waite@crocodile-rcs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hi Carlos, Carsten,<br>
From a bit of code inspection, it looks like this affects the
error paths for the diameter responses.<br>
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).<br>
<br>
<tt>Dec 15 12:13:23 kamailio kam-scscf[22542]: ERROR:
<script>: We need to do an UNREG server SAR assignemnt</tt><tt><br>
</tt><tt>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]</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>Dec 15 12:13:23 kamailio kam-scscf[22553]: ERROR:
<script>: Unknown return code from SAR, <b>value is
[<null>]</b></tt><tt><br>
</tt><tt>...</tt><tt><br>
</tt><tt>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]</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>Dec 16 17:53:57 kamailio kam-icscf[23666]: ERROR:
<script>: Unknown return code from UAR, <b>value is
[<null>]</b></tt><br>
<br>
I think there are two issues:<br>
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 <tt>'error:'</tt> 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.<br>
<br>
<tt>Dec 17 16:41:07 kamailio kam-scscf[25089]: ERROR:
<script>: We need to do an UNREG server SAR assignemnt</tt><tt><br>
</tt><tt>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]</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>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</tt><tt><br>
</tt><tt>Dec 17 16:41:07 kamailio kam-scscf[25099]: ERROR:
<script>: <b>SAR error - error response sent from module</b></tt><br>
<br>
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.<br>
<br>
Let me know if there are patches you want me to try.<span class="HOEnZb"><font color="#888888"><br>
<br>
Hugh</font></span><div><div class="h5"><br>
<br>
On 15/12/2013 21:17, Hugh Waite wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
Hello,<br>
I am seeing a crash within the latest ims modules using the
example cfg scripts. It also happened in 4.1<br>
<br>
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.<br>
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)<br>
3) The coredump shows that the AVP lists are nonsensical, so the
action to get $avp(s:saa_return_code) causes a crash.<br>
<br>
Do the avp lists need to be re-initialised from the suspended
transaction, like in the 'success/done' section (cxdx_sar.c:252)?<br>
Maybe someone who is more familiar with this code can shine some
light on this?<br>
<br>
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?<br>
<br>
Regards,<br>
Hugh<br>
<br>
Backtrace:<br>
<blockquote><small><tt>(gdb) bt</tt></small><br>
<small><tt>#0 0x000000000053dc89 in match_by_name
(avp=0x303630363a6d6f63, id=116, name=0x7ffff29895f8) at
usr_avp.c:391</tt></small><br>
<small><tt>#1 0x000000000053e411 in search_next_avp
(s=0x7ffff29895f0, val=0x7ffff2989630) at usr_avp.c:507</tt></small><br>
<small><tt>#2 0x000000000053e120 in search_avp (ident=...,
val=0x7ffff2989630, state=0x7ffff29895f0) at usr_avp.c:475</tt></small><br>
<small><tt>#3 0x000000000053de09 in search_first_avp (flags=1,
name=..., val=0x7ffff2989630, s=0x7ffff29895f0) at
usr_avp.c:427</tt></small><br>
<small><tt>#4 0x00007fa8de2f5626 in pv_get_avp
(msg=0x7ffff298a030, param=0x7fa8de86b898,
res=0x7ffff2989760) at pv_core.c:1475</tt></small><br>
<small><tt>#5 0x0000000000499270 in pv_get_spec_value
(msg=0x7ffff298a030, sp=0x7fa8de86b880,
value=0x7ffff2989760) at pvapi.c:1266</tt></small><br>
<small><tt>#6 0x00000000004c5f03 in rval_get_int
(h=0x7ffff2989ef0, msg=0x7ffff298a030, i=0x7ffff2989d58,
rv=0x7fa8de86b878, cache=0x0) at rvalue.c:978</tt></small><br>
<small><tt>#7 0x00000000004c89f5 in rval_expr_eval_int
(h=0x7ffff2989ef0, msg=0x7ffff298a030, res=0x7ffff2989d58,
rve=0x7fa8de86b870) at rvalue.c:1918</tt></small><br>
<small><tt>#8 0x0000000000420648 in do_action
(h=0x7ffff2989ef0, a=0x7fa8de86eaa8, msg=0x7ffff298a030) at
action.c:1219</tt></small><br>
<small><tt>#9 0x0000000000422878 in run_actions
(h=0x7ffff2989ef0, a=0x7fa8de86aa30, msg=0x7ffff298a030) at
action.c:1599</tt></small><br>
<small><tt>#10 0x0000000000423017 in run_top_route
(a=0x7fa8de86aa30, msg=0x7ffff298a030, c=0x0) at
action.c:1685</tt></small><br>
<small><tt>#11 0x00007fa8de59eae3 in t_continue
(hash_index=15710, label=170389234, route=0x7fa8de86aa30) at
t_suspend.c:245</tt></small><br>
<small><tt>#12 0x00007fa8da1ebc98 in async_cdp_callback
(is_timeout=0, param=0x7fa8d5c68f40, saa=0x0,
elapsed_msecs=1) at cxdx_sar.c:290</tt></small><br>
<small><tt>#13 0x00007fa8db23cacb in api_callback
(p=0x7fa8d5c24d40, msg=0x7fa8d5c5aca8, ptr=0x0) at
api_process.c:115</tt></small><br>
<small><tt>#14 0x00007fa8db27ad87 in worker_process (id=2) at
worker.c:330</tt></small><br>
<small><tt>#15 0x00007fa8db257aea in diameter_peer_start
(blocking=0) at diameter_peer.c:309</tt></small><br>
<small><tt>#16 0x00007fa8db25a02b in cdp_child_init (rank=0) at
mod.c:237</tt></small><br>
<small><tt>#17 0x00000000004f7ec2 in init_mod_child
(m=0x7fa8de841158, rank=0) at sr_module.c:924</tt></small><br>
<small><tt>#18 0x00000000004f7d65 in init_mod_child
(m=0x7fa8de841d00, rank=0) at sr_module.c:921</tt></small><br>
<small><tt>#19 0x00000000004f7d65 in init_mod_child
(m=0x7fa8de8420a8, rank=0) at sr_module.c:921</tt></small><br>
<small><tt>#20 0x00000000004f7d65 in init_mod_child
(m=0x7fa8de842458, rank=0) at sr_module.c:921</tt></small><br>
<small><tt>#21 0x00000000004f7d65 in init_mod_child
(m=0x7fa8de842ae8, rank=0) at sr_module.c:921</tt></small><br>
<small><tt>#22 0x00000000004f7d65 in init_mod_child
(m=0x7fa8de842f60, rank=0) at sr_module.c:921</tt></small><br>
<small><tt>#23 0x00000000004f8048 in init_child (rank=0) at
sr_module.c:948</tt></small><br>
<small><tt>#24 0x000000000046d57c in main_loop () at main.c:1694</tt></small><br>
<small><tt>#25 0x000000000047030b in main (argc=13,
argv=0x7ffff298af78) at main.c:2533</tt></small><br>
</blockquote>
<br>
<br>
<pre cols="72">--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.</pre>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</div></blockquote>
<br><div class="im">
<br>
<pre cols="72">--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.</pre>
</div></div>
<br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Carlos<div><a href="http://caruizdiaz.com" target="_blank">http://caruizdiaz.com</a></div><div>+595981146623</div>
</div>